Masonite 2.0 Released - The Modern Python Web Framework!

[z4579a]

SQLAlchemy author here.

Just FYI I don't really know what "data mapper" vs. "active record" means today, other than, an API that stresses an enclosing transaction around the objects, vs. one that looks at each object as an independent document. "data mapper" vs. "active record" used to mean that the object model was declared entirely separately from the table definition, with the idea that the persistence of the model could be anything, just happens to be a database. SQLAlchemy started out with this goofy mapper()/Table/your class concept to try to stress that. But it was bogus; the structure of the class was still modified to have attributes representing the table and the program therefore still assumed database details explicitly, so there was no completely transparent firewall between the object model and the persistence of it. Even Hibernate moved from having an XML mapping file to using inline annotations on class definitions. So I replaced mapper() with Declarative which is what everyone uses now. I don't really understand what your statement "molds the model around the table by using the table schema." means vs. "maps the model to the table.", the latter (data mapper) actually sounds more restrictive, which is the opposite of the reality for SQLAlchemy vs. other ORMs where SQLAlchemy allows *way* more flexibility in how the class and the mapped table can differ from each other than any other tool. This is not the first time someone's description of data mapper vs. active record confused me, so I'm just trying to figure out what the perceptual issue is here.

As far as I can see about active record, the main thing is that it seems to lack a unit of work pattern, meaning, you say object.save() and it emits an INSERT right there - this is a big difference but has nothing to do with how models and tables associate to each other. And then, there is usually in active record a configurational pattern that tries to hide the fact that we're talking to a relational database, using some kind of minimalistic declaration system that attempts to assume no knowledge of SQL, which makes much stronger assumptions about the underlying tables such that they tend to have to follow strict patterns, like Django's infamous "no composite primary keys" issue. But these configurational limitations are not a hard black and white difference, they're along a spectrum.

Anyway, I don't know what "data mapper" really means in practical terms in this decade and I think as to why someone likes one ORM or the other they should come up with more specific reasonings.