Page 2 of 2
Posted: Sat May 12, 2007 9:00 pm
by Kieran Huggins
record "collections" is an issue I'm trying to address in Querify (was: kQuery) - I like the way jQuery deals with objects and collections, it makes sense to try and apply the same concepts to ORM.
As people have stated before: ORM is not a magic-SQL-bullet. However, if it speeds up 95% of your development, I would consider it to be a success.
Posted: Sat May 12, 2007 11:47 pm
by wei
wow, 95% that is a pretty high expectation

, i would consider 50% a success as to factor in gotchas that any design will inheritantly have. I guess it also depends on the proficiency of the current user. I would also consider maintanance a criteria, e.g. how would someone else react to the code if you decide to leave the project that uses some sort of ORM (assuming that the new person have not use that ORM before, as this will be most likely in the PHP areana).
Posted: Sun May 13, 2007 12:59 am
by Christopher
I have never found O/RM to speed up development -- in fact it usually slows things down. What it does provide is a major flex point between the OOP design and the database schema. Especially with a changing database schema. That is the problem that O/RM was intended to solve.
Kieran, I think that (and perhaps others in this thread) are taking about Query Building rather than O/RM. It is confusing because O/RM systems often resort to implementing Query Builders -- but that is usually to make their job easier, not yours.
Posted: Sun May 13, 2007 10:45 pm
by Kieran Huggins
@arborint: I'm totally thinking about query building to a large extent - it's difficult to separate it from ORM in my opinion.
@wei: 95% is an awfully high estimate, but it helps keep me motivated

In actuality I only meant the development time associated with data retrieval, manipulation and storage.. not the entire development process!
Posted: Mon May 14, 2007 8:00 am
by Begby
I spent a lot of time in the past trying to build ORM classes and they all sucked. The problem was that they were never flexible enough for complex queries. Recently I have begun working with much larger projects primarily coding abstraction layers to the backend for other teammates, and this has changed my perspective.
Instead of trying to build a set of very flexible ORM tools that will work with everything, I now code from pretty much scratch a ORM class for each entity using a set of interfaces/patterns.
This has changed my perspective from "how will this code translate into SQL joins and what not and be flexible" to "How can I code this class so it makes the most sense when I or the other developers are using it". I also need to keep this flexible enough so at some point I could easily replace the backend with a different database or even something more extreme like moving to a complete web services backend.
What this has resulted in is a set of three classes for each entity (keeping in mind that an entity might span 10 tables).
Collection class for working with more than object
Manager class for reading and writing from the database
Entity class which is a representation of the object containing data, validation code, business logic, but no actual SQL.
I also have a parameters class which is analogous to the propel criteria class. I had to add this in as I was creating way to many manager methods. I might need to make this entity specific but we'll see.
I figure out how I am going to create the entity class by typing in how it should work in code while ignoring the database structure completely. For instance our backorder database structure is really complicated, but I don't want any of that complexity in code. Using an ORM mapper like propel would make it even more confusing. I just have a releaseBackOrders() method in the manager class that has the required SQL all laid out in an easy to follow fashion.
When I add an order, then add products to an order, the API does not mirror the database structure. Instead I set it up so that its make sense and is easy to use. The manager class sorts it out and creates the SQL.
Posted: Mon May 14, 2007 3:52 pm
by Kieran Huggins
thanks for that Begby - I've always been worried that I'm trying to build a swiss army hammer. I'll keep developing this for now, just out of curiosity, but I can completely see your point.
Posted: Thu Aug 30, 2007 3:04 am
by marcoski
Hi all,
Is an Object Relational Mapping library the case where apply any concurrency rules?
In detail, following
viewtopic.php?t=48499 implementation design, is the DataAccess object affected of any lack of concurrency or DBRMS subsystem deals those problems?
Thanks all