4 ms·
Except that an XML file that passes the spec and contains the required data is as good as it will ever get. The world's foremost XML-typing genius is not going
by nerdbert 3y ago
Except that an XML file that passes the spec and contains the required data is as good as it will ever get. The world's foremost XML-typing genius is not going to improve on that.
On the other hand, with hibernate, you get mediocre, inefficient SQL, and could produce much better results by focusing your energies on learning the database instead of learning hibernate.
- makeitdouble 3y ago> The world's foremost XML-typing genius A thought exercice: XML entities can be self referencing, have you ever though of how you validate a document that has recursive entity definitions ? That's one quirk that comes first to mind, but the XML format definition is probably at leat a few hundred pages and I'm hopeful there's enough in there to fuel anyone's worst nightmares. It's kinda interesting in itself that XML is seen as a plain and boring data format. I don't wish on anyone to be the receiving end of an XML typing genius' documents.
- Mikhail_Edoshin 3y agoThe size of specification is easy to check. The print button say XML 1.0 spec is 37 pages long. By comparison YAML is 65 pages. XML is not too simple, but it is not too complex either.
- riffraff 3y agoThe xml spec needs to be complemented with xsd, relax-ng or whatever schema tool is popular these days, yaml includes that. Still in the same ballpark I expect.
- funcDropShadow 3y agoWhich kind of schemas are part of yaml? Interestingly although Yaml's spec is longer than XML's spec, it managed to get all sorts of corner cases awefully wrong. https://noyaml.com https://noyaml.com
- riffraff 3y agoI mean YAML has tags (!!MyType) and built-in types like date etc which XML does not. It also solved the "no" issue and many corener caes in YAML 1.2 which has been out for 15 years or so, but libraries have not upgraded.
- Mikhail_Edoshin 3y agoThe XML specification does contain a schema: the DTD. This is why it is 37 pages; without the DTD part it would be at most a half of that. Other schemas are not merely popular, they are more powerful. In DTD the type of the element depends only on its own name. In XSD the type depends potentially on the context: the type of 'xxx' in 'aaa/xxx' and 'bbb/xxx' may be different. And in Relax NG we can define different types, for example, for the first 'xxx' and for the subsequent 'xxx's. These extensions make the validation somewhat more elaborate, but still linear, as it we remain within the complexity of a regular expression. These are formal validators; then there is Schematron which seems to be more like a business-rule kind of a validator that also has its uses.
- makeitdouble 3y agoI am surprised at how short it is. I think I was seeing all the XSLT and XQuery and all the kitchen sink directly bound to XML, but those are just meta tools that don't bear directly on the language.
- lmm 3y ago> could produce much better results by focusing your energies on learning the database instead of learning hibernate. Completely false IME. If you put the same amount of effort into learning Hibernate you'll get a much bigger return.
- krzyk 3y agoIs there a way to avoid anemic domain model? Or have a proper invariant entity class that is created using constructor?
- lmm 3y agoNo. I see that as a reflection of the reality of the database; if your database contains rows that violate your domain invariants, what would you expect to happen?
- ivan_gammel 3y agoIt may not be a bad idea to fail fast by ORM calling the constructor (same way as Jackson does it when parsing JSON). Broken invariants may propagate and cross system boundaries making things much worse (I have seen a case, when $200M transaction was rolled back in 19 systems because data was not properly validated at entry - it was a crazy day for everyone in production support).
- krzyk 3y agoI hope application to break as soon as possible so everyone will be on board to fix it.
- makeitdouble 3y agoOn hibernate: there is a common approach of having pure ORM handling of 99% of the queries and use a lower level query building tool for the 1% that needs it. The query to fetch your user profile should be mediocre, properly cached, and fully defineable in the ORM. And most of your queries should be straight and obvious joins between tables with no crazy pants handling. Something in your basic data structure that throws off an ORM would also probably throws off your new employees looking at the code for the first time, and could be fixed for readability and maintainance.