recommendations on ORM vs custom data mapper

[eluser]toopay[/eluser]
I doubt you can found that definition on google, it is actually based by standard o'reily book (written by a veteran Flickr developer) which i read several years ago while i started my first "large" application. I believed starting discuss about that would be useful for developer at any level.

And please do not apologize for that, I'm really apreciated, you bring that issues/term of scalability into this thread, because indeed it is the reason we should be when we talk about ORM, even you deliver it with your (standard sarcastic and provocated ;-) ) style.

[eluser]Nick_MyShuitings[/eluser]
I'm hurt... standard sarcastic style... sniff sniff nake:

Do you recall which O'Reilly book it was? or if they have a new version? I'm always looking for a new read.

[eluser]toopay[/eluser]
This book.

[eluser]gh0st[/eluser]
I've enjoyed using DataMapper for my project, its pretty big at the moment; but it does handle all the relationships, etc.

Sprig is the closest thing I've seen to the way Django handles ORM. It was really cool to use, but I don't know enough about Kohana to really do anything with it.

[eluser]Chillahan[/eluser]
Wan_Wizard, is there anything about the Data Mapper code that would indeed affect scalability? I figure that, since there is no data persistence in the usual PHP web app on the web/app server side, a multi-homed architecture would be no issue, correct? (but I assume there's extra garbage collection to be done, or can PHP be relied upon to do that if a session stalls or gets dropped by the end user and times out? with CI it's all singleton, so no concerns there, but each new Data Mapper object does allocate memory, right, so at some point it's got to be deallocated...)

I think the only scalability concern, assuming front end servers can be scaled out, is how hard the database server gets hit, since it's a harder resource to scale out (and usually is scaled up rather than out).