4 ms·
this reminds me of that one table with more than 255 columns which hibernate converted into a class that could not be compiled since the constructor had too man
by LoSboccacc 8y ago
this reminds me of that one table with more than 255 columns which hibernate converted into a class that could not be compiled since the constructor had too many parameters. we split it up using the component mapping to realize some of these column as if they were composition.
the early '00 were a lawless wasteland.
- LanceH 8y agoIf you were using Hibernate in 2000 and not caught up in the EJB hype, you were ahead of the game.
- LoSboccacc 8y agomaybe because I was fresh out of academia then but neither xml defined behavior nor the ejb looked like something that really removed work, moreover I've always been biased against things I can't put a break-point and debug in the event of having issues (which is also why I skipped on angular, for example).
- maaaats 8y agoAh, reminds me of something I had to do only two years ago. Business side would send an excel file with thousands of lines and some columns with some definitions. These we would export to csv and turn into a huge enum using some generator. One definition per line in the excel document, on the form Rule67_Oslo(245, 167, NO_TRANSFER). One day it failed, as the byte count was too big. Managed to strip down the definitions some, but a few weeks later it was impossible to add new rules again. No idea why someone would make that design in the first place, old legacy system. But it was hard to refactor as well, as those constants were littered everywhere in the code as well. I switched teams before it was solved, but I think the fix was mainly that business had to find one rule to remove every time they wanted to add a new one..