Just a thought about Object Relationa-mapping, which I was thinking about and discussed with a friend yesterday.
He gave me the following metaphor for what Object Relational Mapping is doing for you:
Imagine:
You’re driving home after a long day at the office;
Once you enter your lane and arrive at your garage door, you open it;
In you’re garage you have a warehouse with plenty of boxes; (database)
You start disassembling your car and put every single part in the box which is at the right location and has the right label for this part;
It’s easy because your warehouse is well structured and you have the tools for disassembling your car. If you need, you can really find any single part and probably you can temporary use it for other purposes.
Once every single part of your car has been put on the right stock-location, you switch off the light, close the door of your garage and say hello to your beloved wife and children.
-Enough for today.
Next morning, you open the garage/warehouse door because you need to go to office again;
You have a look at the technical paperwork and start assembling your car again;
It’s very well documented, you have perfect tools optimized for this job, because you do it every day;
Finally you see, there is nothing left in your garage/warehouse so you expect the car to be assembled well and ready to go. No need for testing because you’re have done everything very accurate;
Let’s start the engine and go to work.
For your convenience you leave the car assembled during your working day, since it is accepted to leave it running unattended on the parking area with some subsystems of the car still running.
In your code you don’t worry about “rows of data” you deal with “people, cars” and all the other objects your app is concerned with.
And these objects can be put into a database or retrieved from a database without having to write a lot of sql.
So once you have a “person” object you might get at their related contact info by something as simple as
contactInfo = person.ContactInfo()
No query, no sql, you just ask the object for its contact info (phone, email, etc)
However even in very mature ORM systems they usually include a means to get at “raw results” (different systems have different names for this) where you DO get rows of data instead of objects representing cars, trucks, people or whatever else your app is involved with.
The pluses are that your code can be simpler and actually more maintainable and more robust because you’re NOT writing sql every time for everything.
The downside is sometimes the insulation from having direct access to the db means you have induced some slowness (to reassemble objects from the database tables) and that getting direct access to the db for bulk operations using sql is less amenable.
Hi guys, I tried to translate my understanding of OR-mapping into simple real-world things to explain that it’s rather inefficient.
I know Bob Keeney has ActiveRecord + class generator, good stuff. Like his approach and way he implements it.
But … I am thinking of a universal time-aware storage based on introspection and just a little SQL which gives me extreme flexibility combined with less overhead compared to OR-maping. Of course it’s fully OO.
ORM doesn’t HAVE to be inefficient though
The way it’s implemented has a huge impact
iTunes & Apples web store are all based heavily on WebObjects & use ORM
One thing that none of the existing implementations for Xojo have is an object cache
This makes an enormous difference since every time you request something it has to be rebuilt from disk
In something like WebObjects (& many other ORM systems) there is what can best be described as a “write through cache”
For xojo it would have to be in process but for WO its a separate process that the app talks to - it NEVER talks directly to the data store (db)
What this means is that when a change is made the objects data is written to disk but the object is cached and maybe eventually released on an LRU basis.
So if you use an object a lot it’s already in the cage in the right state & you spend 0 time getting it back.
ActiveRecord isn’t the speediest nor most efficient way to work with a database. You have to program in the relationships and how you retrieve it. While that’s not hard, it’s not a trivial task either.
What AR does is it allows you to have AutoComplete of tables and fields and the compiler will squawk if you try to put wrong data types into a field. It also warns you of missing fields in your classes. Every db operation is transactional and uses prepared statements - all without the developer really needing to do much.
In other words, it’s a class based approach to working with databases and tries to eliminate most of the most common issues. It’s also faster to develop in than many other approaches. A little bit of setup time but a big payoff during development (in our experience).
I am retrieving the relationships between tables from the foreignkeys definitions of the sql statements
I’m surprised ActiveRecord does not do the same ?
My experience with Xojo has been, that ORM makes only sense if you have a rich domain model and a pure one, which is difficult to achieve. When you have an anemic domain model even only partially , it makes more sense IMHO to go with dumb DTOs instead of ActiveRecord. Yes, you’ll have some code copied for reading and writing the database, but it is only a few lines. It is also a bit faster.
There is also Valentina Database, which is both natively object relational (and with Joins compatibility) and fast. It uses massively the cache, and tables/fields are objects in Xojo. It is also a NoSQL database (both SQL and a Xojo native language can be used for requests. But for the latter, only on non-server databases). For the server, there is a system of lock for data isolation, but it has not yet transaction system itself (rollback).
ActiveRecord has saved me tons of time especially in the debugging area. Before using ORMs, I would code everything by hand and when the scheme would change (like add another column) my code would break. And I would have to go through the whole code base finding places that I needed to fix. And a lot of the time it would not fail or cause issues until run time. Now with ORMs it keeps me in check to make sure it will work as designed and desired.
