That's not versioning, it's a query.
I thought database versioning was one of the "classic hard problems" with databases. Have you found a magical solution to this problem that the rest of us have missed? I look forward to your "modicum of imagination" on this topic.
| [reply] |
I thought database versioning...
Re-read the context. Modules have version numbers. Sometimes you need to retain access to an older version of a module for one application, whilst moving to using the latest version for new applications. Retaining access to both (or more) versions of the module within the same Perl installation is a problem not currently easily addressable.
The simple expedient of adding a "Version" field to the "Modules" table would allow each application to request any of: the latest version; a specified version; any version before (or after) a given version; etc.
In this context, I chose the word "versioning" to describe that possibility.
Whatever other interpretation you have chosen to read into my use of that word in this context--is wrong.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
Rule 1 has a caveat! -- Who broke the cabal?
| [reply] |
Remember this, though: just because a record in the database says there is a version 1.2 doesn't mean it actually exists.
The database can store a field it calls a "version number", but that doesn't enforce anything on reality.
I would like to simultaneously store different versions of the same module (I'm looking at you, CGI.pm!), but that's not a issue that a database record will fix. We still have to have some way to store it. Once we have that, we'll be able to figure out which version to get even without a database.
So, I don't see how the database is doing anything special here, or adding value. I certainly don't think it is doing any "versioning", in any context.
--
brian d foy <brian@stonehenge.com>
| [reply] |