Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Why didn’t they just gen their data classes from the db so the code would break if they were out of sync ?
The rest I’m not seeing though
More details as to why this was so complex ?
The early part sounds like a template system
So if they were using something to display these forms you’d be able to figure out what they were for -
@MadMadMadMrMim because the db stored everything as XML to allow for arbitrary data from forms.
Later they added some fields extra for better index performance.
And yes it was an older system, used for the wrong purpose, not designed with performance or for scale and very adhoc.
A true legacy system in many cases ;)
As I said, we did not buy it for the code and they where going out of business due to bad code, I am pretty sure there is a lot they could have made better but obviously lacked skill or understanding enough to do. -
@Voxera personally I never understood xml
I even took a class in it in college when it was a new concept and we had the sax engine
I’ve always thought it was crappy for anything but a description of small chunks of data and now we have Json if we want bloat -
@MadMadMadMrMim XML as such is not a bad idea. Used with a schema it was excellent for interoperability but it had limits.
In this case they where trying to use an sql db as a nosql in probably the worst way, duplicate data, undocumented XML And the stored documents contained references to actual code, linking it hard to classes and methods ;)
If you wanted to change the method you had to ad the new one, update all objects referencing it then remove the old.
And with no documentation that would be very hard.
As I said, legacy :)
Json is more compact than XML but xml has properties which if used in a consistent way can add context to data.
But you need to have a schema for that to be really useful. Many hone grown xml usage lack consistency which means it can be very hard to use.
For really advanced usage you add XSLT which is a transformation language that can take one xml and transform it into some other format or a new xml with different structure.
That was often used to convert data in integrations.
But its a bit like regex, very powerful, few know haw to really use it an most make a mess of it :P -
Xslt was a basic thing we learned at the time and it’s cumbersome and not really any better than xml
If I remember correctly that’s what sax was used for to load document and xslt and run the queries and transform it into some other document
It was clunky
Probably still is
It’s like m4
Good idea bad implementation -
@LotsOfCaffeine yes, I was very happy we only had to learn enough to help the customers escape and then ditch the monstrosity ;)
-
@Voxera it’s a document formatter
You can mimic the same and more with some for loops and an xml lib -
@MadMadMadMrMim its more than that, and sure you can do it with code but I actually think fore any more complex transform xslt can be more compact.
Also, its actually quite fast in modern xslt engines.
But I almost never use it any more.
As you said, you can do most of it in code, and the odds are that any one else needing to look at it will understand the code better anyway ;)
Adding a feature to 18 000 undocumented lines of code, written in PL/SQL. Oh, did I mention it was just a sing...
On my former job we once bought a competing company that was failing.
Not for the code but for their customers.
But to make the transition easy we needed to understand their code and database to make a migration script.
And that was a real deep dive.
Their system was built on top of a home grown platform intended to let customers design their own business flows which meant it contained solutions for forms and workflow path design. But that never hit of so instead they used their own platform to design a new system for a more specific purpose.
This required some extra functionality and had it been for their customers to use that functionality would have been added to the platform.
But since they had given up on that they took an easy route and started adding direct references between the code and the configuration.
That is, in the configuration they added explicit class names and method names to be used as data store or for actions.
This was of cause never documented in any way.
And it also was a big contributing cause to their downfall as they hit a complexity they could not handle.
Even the slightest change required synchronizing between the config in the db and the compiled code, which meant you could not see mistakes in compilation but only by trying out every form and action that touched what you changed.
And without documentation or search tools that also meant that no one new could work the code, you had to know what used what to make any changes.
Luckily for us we mostly only needed to understand the storage in the database but even that took about a month to map out WITH the help of their developer ;)
It was not only the “inner platform” it was abusing and breaking the inner platform in more was I can count.
If you are going down the inner platform, at least make sure you go all the way and build it as if it was for the customers, then you at least keep it consistent and keep a clear border between platform and how it is used.
rant
wk266