[nycphp-talk] Never heard that term: Viet Nam of programming
Hans C. Kaspersetz
hans at cyberxdesigns.com
Wed Jan 24 21:15:20 EST 2007
I believe this is where I will make a fool of myself, but I will give it
a shot anyway.
1. Yes, we scratch built the system in house.
2. Your correct, if we make a change to the schema of the database we
have to represent that change in data model. If we remove something
from the database and don't reflect that change in the data model the
system complains. However, this seems like a very small price to pay.
The data model is the representation of all the objects in the system.
If I want to know what is in an object, I go to the data model and check
its relationships and attributes. The methods for each object are not
in data model, they are defined in the
3. Our system is not zero configuration. If you want access to
something in the db you have to put it in the data model. We also have
to configure all our db brokers.
In our system all we have to do is load the parent object:
$Hans = new Person();
I now have access to all the objects that $Hans knows about. If I want
to update Hans:
$Hans->Name = 'Sue';
If the Person object knows about the address object and the address
object knows about the location object (which is all defined in the data
model) I access them by:
$Lattude = $Hans->HomeAddress->Location->Latitude;
It should be noted that we have ways of defining a name for a
relationship in an object. So, we might call the address relationship
for the person object HomeAddress and only select home addresses when we
call $Hans->HomeAddress. If we called $Hans->Address, if we defined
it, we might get back a set of all of Hans' addresses. In which case we
have an iterator to go over them. $Hans->Address, $Hans->Address,
The ORM fetches the relations and data automatically. If we eager
loaded it, it will already be in the object, if we didn't eager load it,
the system makes the sql calls to find it just in time. We define on a
per relationship level if we are going to eager load or not. As you can
imagine, eager loading is expensive.
I am truly not the expert here, I am not even sure how it all works on
the inside. I leave it to those smarter then me to work it out. What I
can tell you is that it currently works for us.
The blog post by Ted Neward is a very interesting read. Now I am going
to pay attention to where we fall victim to his assertions.
> Is this a system you've built in-house?
> I've certainly seen places where ORM was as much of a problem as it
> was a solution. On the other hand, I've done more than my share of
> maintainance on applications where sql code is distributed throughout
> the application, and (worse) applications where people developed a
> database layer which encapsulated bad practices and bad assumptions
> about the problem domain.
> One basic trouble with ORM is that it violates the principle of
> "don't repeat yourself;" you have to maintain a database schema ~and~
> an object hiearchy. Change one, and you have to change the other.
> Another problem is that there is a semantic mismatch between objects
> and sql -- there are three ways to represent inheritance relations in
> sql, and all three are unsatisfactory in some way.
> I've been working lately with a minimalist "active record" that
> introspects the database, and lets you write something like
> it saves a lot of fumbling with 'addslashes' or '?' parameters,
> thus eliminating a common kind of repetitive coding. It doesn't try
> to map database 'rows' to anything else, but it can still automate
> certain aspects, such as timestamping changes to rows, and keeping
> an archive of who changed what when. I've been trying to develop
> something that does 20% of the work and eliminates 80% of the pain of
> writing "plain old" applications with lots of SQL. So far the system
> is zero-configuration, although I'm sure I'll add features to it
> someday that require some configuration -- for instance, I do see an
> easy way to implement a certain kind of inheritance.
> ORM systems do get interesting, however, in architectures that
> really take advantage of the objects. For instance, if you can
> design your objects so that aspects cut across them, you can build
> really powerful systems quick.
> New York PHP Community Talk Mailing List
> NYPHPCon 2006 Presentations Online
> Show Your Participation in New York PHP
Hans C. Kaspersetz
Cyber X Designs
hans at cyberxdesigns.com
More information about the talk