That's the same debate as whether you to hand craft xml files or have a library do it for you. You'd better know in details how the format works, but going through a library will help cover most common issues you wouldn't want to deal with by hand.
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.
On 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.
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.
The 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.
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.
No. 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?
It 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).
That comparison would only really make sense if people were advocating writing SQLite storage files by hand.
In this situation SQL is the library. It’s the interface that allows you to query and write the underlying data while knowing nothing about the underlying format. An ORM is just a library sitting on top of the library you already have. There’s just as much to learn, it’s just a higher level of abstraction (until it isn’t because you need something low level).
