UUID
So back in July of 2024 a number of us got pulled off of our work and put onto a project that was to modify every table we have in our system. The project was to add 2 columns to every table, a UUID and a Version Number. Although it was to be done as a single project the reason each field was to be added was to support completely separate process. This was done with 5 weeks left in the normal development of our release and we have around 80 tables to modify. Not impossible if handled correctly. The problem was and is the UUID field and the fact the project was not handled correctly.
A UUID for those of you who don't know is a Universally Unique Identifier and consists of 16 bytes (128 bits) of information that are generated in various ways. There is a Wiki page all about it if you want to delve into it. For the purposes of our discussion it is a unique number assigned to each row of every table. The following is what I wrote as my recommendation.
The problem is that, because of the makeup of our system, we do not have a way to natively store a UUID and interface it between the systems. [ed note: The core of our database is 40 years old.] We have not implemented a UUID data type in the database and as most interfaces are generated based on the database schema, that would need to be implemented first. For the interfaces between our systems we also did not implement a datatype for a UUID. We can implement this, but it will take time due to the many touch-points (2 schemas, 4 interfaces, 3 primary DBs, 2 secondary DBs) it cannot be completed in the time available. My recommendation is that for this first pass on the limited set of data files we have selected for the pilot, to store the UUID in its text format as a 36 character field then in the next release implement a UUID datatype across all the touch-points, convert the text field to a UUID in its binary 16 byte representation, and add the UUID to the remaining tables. A 36 character field is something that we know will flow through the entire ecosystem using the existing tooling we have built.
This was rejected out of hand, within minutes of me sending the email. Until the day of my “Now it makes sense” post I did not understand why. We pushed forward with a bodged together handling of the UUID in its binary form into all systems and interfaces for a limited set of tables. This one project pushed that release’s completion date out 8 weeks in total with 2 major pre-release issues and one post-release issue caused by the UUID work. All of the work required extensive overtime by multiple individuals and resulted in several secondary databases on client systems to be corrupted, requiring extended recovery support work. All of this development will need to be redone, every last line of it every table definition entry. It is all exception coding and barely working schema entries.
And the worst part of it is that the downstream platform that this was done for is in an early development phase. There was no need to put the production release at risk it could have waited one release. The other problem I have with this is that the new platform has been under development for almost 2 years at this point, so why was the requirement for us to implement a UUID handed down in such an abrupt manner with a get-it-done deadline.
posted by MrPopman @ 9:21 PM
0 Comments:
Post a Comment
<< Home