NYCPHP Meetup

[Hans C. Kaspersetz]

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();
$Hans->SetId($PersonID);
$Hans->Populate();

I now have access to all the objects that $Hans knows about.  If I want 
to update Hans:

$Hans->Name = 'Sue';
$Hans->Update();

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[0], $Hans->Address[1], 
ect.

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.

Hans
http://www.cyberxdesigns.com

>>
>    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
>
> $table=$db->{my_table}
> $row=$table->fetch($id);
> $row->{count_value}=77;
> $row->update();
>
>    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
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
>
>

-- 
Hans C. Kaspersetz
Cyber X Designs

Office: 201-558-7929
Mobile: 201-681-4156
hans at cyberxdesigns.com
http://www.cyberxdesigns.com