What should I persist in the db to identify a group?
I may need to migrate this to another system IE: Dev to Test
Discussion posts and replies are publicly visible
There's no very easy way to do both.
A group exists in an environment primarily identified by its environment-specific ID (which is just an integer). There is also a UUID that underlies the group, but this is not easy to use (iirc there's no direct way to programatically get a group Object/ID matching a UUID if you have one to start with).
For storing a group in the DB that means the only really good option is storing the Group ID. You can deploy that group to another environment just fine but you *must* build around the fact that its Group ID will almost always be different in other environments.
Hi Mike,If we deploy groups from dev to test, won't they have the same group IDs since the same object is getting moved from lower environment to higher environment?
we have config/template data that we want to publish with our app.
johnf9317 said:config/template data
What part of that translates into needing Group IDs stored in the DB?
OK. Did you consider to implement an API based approach where you transfer that data to the other system using API calls?
The responsible group is tied to a class of data. We have standard groups/levels. These are essentially templates or recommendations but could be different.
Gotcha. You'll just need to design around the Group ID being different when deployed, then. One helpful thing here is, you can create constants that refer to each group in question (assuming your collection of groups will be static and pre-set, versus dynamic and procedurally-created), and of course a constant's group reference will persist between environments, and regardless of which environment you're in, will return the correct Group ID for that environment when you reference it.
wouldn't i have the same problem? I have a groupid in the saved data.... I want to transfer this to the other system. I would still need to translate the UUID to the corresponding groupid in the other system.How its transported isn't the issue. it's translation from UUID to groupid.
This might work or at least make it easier to update the stored groupids. So the deployment "post" process would just need to resaved the groupids that the constants point to. Essentially that is how we store the UUID that needs translation. It's cleaner I like it - Thanks
No. Your objects are defined in the database. When you "send" a new object, you create that group on the target system and store the ID to your table.
Ah I see - that might involve a change in design - but i see how that would work. creating the groups on the fly.
Exactly. It it a bit of effort in the beginning, but makes things super easy later on.
It can be a bit mind-bending when you develop this, because you call APIs on the same system and create new objects in the same table :-)