The JADE 2022 release meets tomorrow’s business demands.
I've been experimenting with the use of the unpublished object versioning functionality, which is what I believe is used for versioning schemas. I'd like to see this published & formally supported going forward.
This capability is something that was mentioned during a prior TOI, as something that may help with source control, and is something I'm looking at using for part of my source control project.
If we had the option of using it, I believe this capability could prove useful in other contexts for applications we develop. This is relevant to scenarios where we need to update complex setup data (i.e. product settings, letter templates). Currently, we need to be careful to commit all changes to data of this nature to provide a consistent view before it takes effect, whereas versioning could allow us to make/load changes in multiple transactions, with a transition phase at the end. In some scenarios, users want the ability to review/approve changes made by others before they're put into effect, for which it may be simpler if we could version the objects as part of this process. It may also be preferable for a prior version to be kept in use for older data, with new versions being used for new records going forward (assuming object versioning could support many versions, rather than just current/latest).
Kevin Saul
hard model: schemaish stuff created by JADE and not by the dynamic methods.
yes, there's physically space on an object to hold versioning info. The fact that you could version an object is a bug.
Did you run a meta certify after? Do know which operations you can run without JADE cleaning up those objects that it thinks shouldn't be there?
Attachments Open full size
I was meaning that if you piggy back on Jade's versioning scheme then Jade won't be able to use that scheme when it needs to version for a reorg, because there's already a versioned instance created by your code (I'm talking about the existing versioning schema which has current and latest versions). It also gets more complicated for the online reorg situation where dual-update mode is in operation after the physical reorg has finished until such time as the transition phase of the reorg is completed.
I'm also not sure there's actually much advantage in using Jade's versioning to support reorg vs just creating your own object which represents the 'pending' version until such time as the changes are approved?
Attachments Open full size
Hi BeeJay - Whether it's our own bespoke versioning system, or JADE's, each new version is a new object, why can't they be re-org'd as usual? When making structural changes, you may have a migration path for which data needs to be upgraded/fixed, which'd apply to all versions - more difficult to do if you've got new/old versions stored in SLOB's.
Attachments Open full size
If you go with the Jade versioning mechanism, how would you ever deploy actual changes to the class structure for those classes as now there's going to be a conflict between Jade's need to version/reorg instances of those classes and your existing 'versioned' instances of those classes with proposed changes which have yet to be approved?
Wouldn't it be safer to create your own user-data versioning scheme on those few classes where you need the concept of reviewing changes prior to them being fully applied? For simple classes, you could store the proposed new version of the 'template' in a SLOB which is an XML or SOAP representation of the proposed changes. When an object has this, un-bust those values into the relevant form fields for reviewing purposes, instead of using the standard properties on the object for those fields. Alternately, you could create another instance of the template class and have a 1-1 inverse between current/new versions of the template. Use the 'new' version when you're opening in 'review' mode, to decide if the changes are appropriate, and use the 'current' version when wanting the template for 'runtime' use.
For the system I work on with templates of this nature, we use the 1-1 inverse between current/new versions of the template as our way of having current vs new and yet to be published/approved versions of the templates.
Attachments Open full size
Can you please clarify what you mean by 'changing the hard model'? Are you referring to the schema entity data implicitly changing as a result of versioning a class instance?
I've already been able to version my own records in a user schema, doesn't appear to be blocked/restricted to system classes only.
Attachments Open full size
Ok, (1) implicitly includes allowing users to change the hard model through code, which we do not allow.
Attachments Open full size
Publishing the existing functionality, documenting how we could use it and current limitations would be the best starting point.
1. Didn't realize there was a major difference between what's there already and what was described at TOI. Once we're familiar with existing capabilities, we'd be in a better position to describe/understand any future proposals to build on what's there already.
2. Nested Transactions, assuming I've understood you correctly, yes, that's a concept we've talked about raising a JEDI for previously (we'd certainly benefit from the ability to rollback part of a transaction during batch processing when an error occurs), but doesn't necessarily relate here. By multiple transactions, I was referring to the possibility of multiple data loads being performed as separate actions.
3. Comments re: reviews are in relation to more general use cases, where users may need to review/approve changes to application data before they're put into practice, not changes to source code. The reason I'm looking at using object versioning for source control is related to tracking changes being made in the latest schema version.
4. General use cases are those where we've a need to manipulate/version our own static/configuration data used at runtime by our applications.
Attachments Open full size
Well, since we're talking about unpublished mechanisms. What is it that you want?
Currently, versioning only works on model classes, and we can only have two versions. Do you want object versioning as described in the TOI, or us to publish our unpublished model versioning API?
Do you actually want Nested Transactions?
Why would you prefer that all these reviews are done in JADE and not in source files where you can get the benefit of the whole industry's standard tools?
Can you think of a general use case?
Attachments Open full size