Need to store group in db - what should i store to identify group?

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?

Hi Sarathkumar R ,

No, The group IDs will be changed

Yeah just now cross verified. Seems only the UUID remains unique
thanks sriram for the clarification.

Yeah, I've only been dealing with variations of this issue for the past ~10 years now

Thank You everyone for the replies.

So I guess with some workarounds getting the UUID/GroupIDs for all group we could make a deployment process that would translate the groupids from one system to the other.

We would need a place to store the UUID that correspond to the groupIDs that need to be changed. Get all the groupid/UUID in the new system and update accordingly..... Something like that.

***
I see a pattern of recurring issues that have been complained about that do not seem to be addressed. I'm not sure what to make of that.

May I ask why you want to store group IDs to database and make that information part of your deployment package?

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.

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.

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