Include a version() method on TEMPLATE_ID

I think opinions differentiate here too much, i and birger agree that its probably better to have a dedicated call to hear everyone out given the impact and consequences this has.
@Ian McNicoll @Sebastian Iancu @Matija Polajnar @Joost Holslag
https://terminplaner6.dfn.de/en/p/095059a03dcee1e64eed6f2bd5bf9b54-1140407?
authkey=e761dd7be7a6f6c2c7bfcd5dd7a1cae04eed3acd908f0306757c5c07c1bd6b82

I must admit I don’t remember ever having a huge issue with not knowing which version of a template a composition was made from; possibly that’s because I don’t remember ever having really breaking changes in the templates. I might be just that I wasn’t involved with any of that…

Putting semantic versions into template_id seems like something that could/should be done just as a documented good practice, without it being enforced. As soon as it is enforced, people (already in this thread) get ideas on how AQL equality comparisons on template_id fields should behave differently than other string comparisons, although they look exactly the same on the outside. While that’s something we already do for timestamps (to resolve timezones and partial values etc.), I’m not very fond of doing it even more. I’m also personally quite allergic to having queries even rely on template IDs instead of merely just archetypes, and yet every single query in our system does that, so don’t take me too seriously on that.

I am with Ian on this one, that another optional (but strongly encouraged for new data) field in ARCHETYPE_DETAILS is an easier way out.

Don’t take any of this an official Better position; it’s just a bag of my opinions. I also have slight fever as an excuse if I wrote anything stupid.

@Ian McNicollIts also only de-facto enforced since you have the header validation=false. Otherwise this cause tremendous amounts of problems i now find people adding clusters for the template id e.g.. So why shouldn't we enforce it given the implications.

The HRID isnt btw part of the RM its part of the object model.

In regards of sem_vers, people already use it, we can adapt what better has or reuse the one of the archetypes in a way or let people decide about their versions. This is just a matter of solving.

Moving the ADL2 you have:
composition that point to a tempalte version (since we enforced it).
compositions that dont have a version and no one knows which template they point to, in case of introducing id you at least can point to the last template that did not have an ID and make a cut there.
So we improve that, not doing that makes it even more messy.

Not doing that is just making the whole migration much much worse, idk maybe you guys kept record but we didnt, no one told us and now we have different version of templates, dont know which compositions do relate to what and what implications this has to our apps and AQLs you can imagine. This is btw for the whole HiGHmed the case.

If we add the namespace as prefix how to deal with legacy data, thats will just cause problems and make things much more complicated. I would like to use it tho, but as said makes the whole legacy data discussion worse.

@Joost Holslag I agree - my assumption was that the new attribute would only ever have a properly controlled hrid identifier, not just some arbitrary string that ‘might’ be a semver (or not). A proper ADL2 template would populate this.

@Birger Haarbrandt - also agree we cannot make this new HRID attribute mandatory for existing data. That was not my intent.

I have no particular issue with your proposed format, Birger but we cannot force that on existing systems, any more than we can enforce HRIDs and TBH I would probably prefer if any new format actually matches an HRID with proper namespaces, and use of ADL2 archetypeIOds for templates. That feels like a cleaner transition.

and as we move into ADL2 we are going to manage systems that have both i.e. compositions based on an older version of a template, labelled with a textual templateID with a more recent version based on an HRID. If there is some way to safely shoehorn both flavours into a single attribute then I’m happy with that but it feels to me to be very tricky to get right. We can’t even really rely on lifecycel_state since this is not enforced by tooling.

We also have to think carefully about what happens in pre-deployment situations

@Ian McNicoll the issue with introducing a new RM field is that it would require existing data to be updated. For me this is the biggest no no when considering changes to the RM (updating billions of compositions is no fun). With adding as suffix (which is anyway closer to the way its done in ADL 2 to my understanding?) and adjusting AQL semantics, we can keep everything from the past as is.