Why no php O/R Mapping tools to date has seen any major community adoption.

[kyberfabrikken]

Well, from skimming through that thread, it seems that there most of the time people suggested what solutions to be included into the ORM tool, not what problems it should solve.

Actually, I think that in this case the form is much more important than the problem. In the case of ORM, the problem is all about form - You already have access to the data-layer, but what the ORM provides is a different interface to the same thing.

More generaly speaking, I'll say that as a programmer, the api of a library is often equaly or more important as it's inner workings, since the api implies how I would have to work with it.

[thr]

More generaly speaking, I'll say that as a programmer, the api of a library is often equaly or more important as it's inner workings, since the api implies how I would have to work with it.

(This is turning out more and more as a "bash ezpdo/propel" thread, but ezpdo is sadly my best worst example). I'd say that the API is not as important as the inner workings, the performance can take quite a hit if you don't got your internal stuff right - take ezpdos 1 > * and * <> * relations, they'are lazyloaded one by one, so a fetching a person and looping his posts becomes: 1+N, the most dreaded query-sequence ever which makes performance hit rock bottom.

[dreamscape]

The same reason that ORMs in PHP don't see major community adoption is probably the same reason that PHP frameworks don't see major community adoption and the same reason that most PHP project's don't see major community adoption.

[DerelictMan]

Ok, maybee the wording non-standardized XML was wrong - my point was that it's something the developer has to learn, yet another layer of code to maintain and keep up to date, learn to use(as it's XML and you have to learn the exact DTD this particular approach offers you).
...
Well, as I said in my above paragraph doing it in XML adds YAL (Yet Another Layer) that needs to be maintianed, learned, etc.

It's just XML, something that most experienced developers have already been exposed to. Any developer who finds learning the basics of creating an XML file to be onerous is probably in the wrong line of work. And you don't have to "learn" the DTD. It's a tool to help ensure that the document matches a specification. It can even provide assistance in the form of context-sensitive completion if you have an IDE that supports it (like Eclipse).

Obviously you have to learn what is expected and required in the XML document, but then again this applies no matter what approach you use for defining the mapping. Let's say you do it all in PHP code. You still have to learn how to do it... what methods to call, what variables to set. The only way you get to bypass learning how to configure the ORM is if it configures itself implicitly based on the database schema which isn't appropriate in many cases and brings with it a whole new set of problems.

Looking at your latest post in the "Feedback on current O/R Mapping Unittests" thread, I see that you describe an approach that expresses the configuration as PHP code, spread throughout the various finder classes. That seems like a workable approach, but I don't find it any less cumbersome than the XML approach. It still has to be learned and maintained. Perhaps you find that XML brings with it inherent complexities that the equivalent PHP code doesn't, and that's a valid opinion, but I personally don't share it.

Runtime introspection can be cached with ease so that's realy no problem.

What are you caching, exactly? Just the database metadata, or the generated classes? If it's the latter then you still have a build process, you are just implicitly running it on the first request. And it isn't like that approach is a panacea, either. Code that is generated on the fly isn't available before hand to build API documentation for. So, what do I do if I want API documentation? I force the build to occur before runtime, and suddenly I have a build system again.

Probably true there, but an ORM with bugs is much much much more serious then your avarage forum software - as other applications depend on the ORM to do it's job 100% correct.

Now that I'm actually looking through my local SVN repository, I see that I've fixed about 3 very minor bugs in Propel, one of which would only be triggered in rare edge cases. It seems that the majority of what I've done is add a few features (enhanced validation, support for left joins, and accommodating some changes I made to the Creole API). So I think it's fair to say that your original claim that Propel contains "numerous bugs" making it unsuitable for production use was not accurate.

I know they exists, but I think you agree on the fact that 95% of the php projects that use EZPDO/Propel just complicates thier problem further because they want to use a fancy solution on a simple problem, which is - yes - stupid.

Umm, I haven't actually examined 95% of the php projects that use EZPDO/Propel, and neither, I suspect, have you, so this strikes me as an odd statement. Do you have specific examples of projects that use one of these technologies that would have been simpler without them?

You might think it's harsh and trivializes what work they've put into it, but I think some of thier design decisions are realy stupid - so why shouldn't I say so?

You're free to express your opinions in any way that you please, just as I am free to take issue with them...

Edit: I realized I made a statement based on an assumption about your approach that was unfounded, and removed it, sorry.

[akrabat]

I discarded Propel because of the build layer. I agree that the whole XML thing is a pain to as it's something else to learn. Clever code, but feels like a lot of work to get stuff done in. IMO Symfony suffers in this respect as you have to learn a lot of command line tools to use it.

I don't like the idea of doc block comments as it just feels wrong. Syntax checking is hard too. It's a clever solution to the problem though but again a new language has to be learnt.

I don't like the idea of database introspection as it feels like a lot of overhead for PHP's setup/teardown on each request system.

The simplicity of a table/row gateway where everything is essentially arrays of fields with helper functions is appealing. Also, SQL is fairly easy to pick up and tune.

As a counterpoint, I like the concept of defining the tables and relations in the PHP class. The downside of course is that you are either repeating what the database already knows or you have to make the PHP code maintain the database strucuture. In some ways letting the PHP code maintain the database structure appeals as it would save having to maintain database schema versioning and upgrade code.


*shrug* I know that I'm confused on this issue

That's why I'm following most of the ORM threads here and playing with Zend's simple Zend_Db_Table.

[BerislavLopac]

Actually, I think that in this case the form is much more important than the problem. In the case of ORM, the problem is all about form - You already have access to the data-layer, but what the ORM provides is a different interface to the same thing.

In any software project, functional specifications are most important; that is also true of ORM.

In other words, we must define what we want our tool to do. Take one of my above requirements as an example:

* has to use an already defined database, ie. the database must be independently accessible by other applications

It is very important to know whether our database should be accessible from other programs, who don't have the benefit of our ORM. Because if so, we should put more thought into the database design and normalization; if not, we can have a simple and universal database layout, which could be generated automatically and is dedicated to persist the objects in the simplest way (e.g. through simple serialization).

[lftl]

Here's my list, by no means complete:

* has to use an already defined database, ie. the database must be independently accessible by other applications
* no hand-written config files (if any are used, they should be automated), XML or any other format
* usable out of the box, at least for the simple cases (e.g. for single PK tables with up to one FK, which are most common on Web) -- no need to write complex table-classes before using it

Interestingly, Propel meets all these criteria. Granted it may not meet your requirements in some other cases, but it fits those.

[thr]

It's just XML, something that most experienced developers have already been exposed to. Any developer who finds learning the basics of creating an XML file to be onerous is probably in the wrong line of work.

Yes, you're probably right about that - but I'd still argue that it makes things more compelx then they already are as in php there is no "real gain" when using .xml files as we don't (normaly, except propel) have a build / compile step and thus don't realy gain anything from using .xml instead of our own language. (I don't doubt you know why Java, etc. has such a big gain from using .xml instead of doing it natively)

Obviously you have to learn what is expected and required in the XML document, but then again this applies no matter what approach you use for defining the mapping. Let's say you do it all in PHP code. You still have to learn how to do it... what methods to call, what variables to set.

Yes, ofc. but that's still in the code which atleast I feel is a subtle but important difference.

Looking at your latest post in the "Feedback on current O/R Mapping Unittests" thread, I see that you describe an approach that expresses the configuration as PHP code, spread throughout the various finder classes. That seems like a workable approach, but I don't find it any less cumbersome than the XML approach. It still has to be learned and maintained. Perhaps you find that XML brings with it inherent complexities that the equivalent PHP code doesn't, and that's a valid opinion, but I personally don't share it.

Yes I'd prefer that approch(I don't wanna get into the whole "my orm is better, no my orm is better"-argument, but I'll answer to this). Yes there's a few methods you'd have to learn (such as hasMany/hasOne/belongsTo/hasInternal and bindField) - my latest ideas are not in the post but If you check later today they'll probably be there - but I'd say that's far for simplier then learning an dtd/spec for an XML schema and then write it plus learning to use the build tool, and build configuration files.

What are you caching, exactly? Just the database metadata, or the generated classes? If it's the latter then you still have a build process, you are just implicitly running it on the first request. And it isn't like that approach is a panacea, either. Code that is generated on the fly isn't available before hand to build API documentation for. So, what do I do if I want API documentation? I force the build to occur before runtime, and suddenly I have a build system again.

I'm not talking about my ORM implementation specificly, and what generated classes are you talking about? If I wanna persist objects I create my classes, and map them to a database - there's no generation here, if I wan't a specialized finder method I add a finder to the "PersonMapper extends Mapper" class - which is very possible to document.

So I think it's fair to say that your original claim that Propel contains "numerous bugs" making it unsuitable for production use was not accurate.

Ok, yeah, it was a bit overhauled and I'll appoligize for it.

Umm, I haven't actually examined 95% of the php projects that use EZPDO/Propel, and neither, I suspect, have you, so this strikes me as an odd statement. Do you have specific examples of projects that use one of these technologies that would have been simpler without them?

No, ofc. I haven't and yes I took it out of nowhere - but I've yet to see any big php project(and tbh I look at quite a lot) that would realy benefit from using an orm - because most of them don't have an complex enough domain model/problem at hand to justify it, imho.

Edit: I realized I made a statement based on an assumption about your approach that was unfounded, and removed it, sorry.

No problem; I was a bit harsh yesterday to(had a bad day maybe) and some of my statements were a bit rude.

Edit:

Reading my initial response to you now, I was a bit harsh and while I don't agree with many of the design decisions of propel my "stupid" statement was a bit.. stupid, from my side

[thr]

Interestingly, Propel meets all these criteria. Granted it may not meet your requirements in some other cases, but it fits those.

Hmm, let's se:

* Has to use an already defined database, ie. the database must be independently accessible by other applications - Check, Propel meets it

* No hand-written config files (if any are used, they should be automated), XML or any other format - No, propel requires .xml config files.

* Usable out of the box, at least for the simple cases (e.g. for single PK tables with up to one FK, which are most common on Web) -- no need to write complex table-classes before using it - No, propel requires definition and building of your objects and relations, I'd hardly say that's "out of the box".

[retro]

I've built my active record implementation based on ADOdb, the code is still in progress of cleaning, but i can upload it somewhere if anyone is interested.

It uses language rules like in RoR Active record.

[thr]

I'm realy starting to thinking about moving towards a TableDataGateway instead as it's much easier to work with, faster and allows for widget-style integration with Views, etc.

RowDataGateway + TableDataGateway, looking very much like Zends implementation but well... a bit different is realy starting to appeal. ActiveRecords seem to pull to much wieght and DataMappers always seem to either 1. pull imense amount of data(hit's performance) or 2. lazyload everything (hit's performance), ActiveRecord is nice, but it's to heavy and cluttered imho(yes I think RoRs AR is nice, but I don't like AR as a pattern).

[DerelictMan]

I'm not talking about my ORM implementation specificly, and what generated classes are you talking about? If I wanna persist objects I create my classes, and map them to a database - there's no generation here, if I wan't a specialized finder method I add a finder to the "PersonMapper extends Mapper" class - which is very possible to document.

You said "runtime introspection can be cached" and then in the other thread you said:

If you don't want any special functionallity there's no need to create the "Person" class as it will be created automaticly at runtime for you - if you wan't other stuff in there go ahead and create your own, etc.

So I just assumed that your ORM generates classes at runtime similar to the way that Propel generates them at "build time". Sorry if I got that wrong.

Maybe I should look at your code more closely before I make any more assumptions. I'll be watching the other thread...

Reading my initial response to you now, I was a bit harsh and while I don't agree with many of the design decisions of propel my "stupid" statement was a bit.. stupid, from my side

No harm done. It's been a good thread, regardless.

[thr]

You said "runtime introspection can be cached" and then in the other thread you said:

Ah, yes... but I was talking about runtime introspection in a more general way ;p not about my orm. Going to move to a table data gateway anyways I think, as the ORM overhead and complexity, etc. uncalled for imho.

So I just assumed that your ORM generates classes at runtime similar to the way that Propel generates them at "build time". Sorry if I got that wrong.

Ah no, the current version just either includes the class file you've written or does an eval on "$class extends ModelRecord" if it can't find it

No harm done. It's been a good thread, regardless.

Yeah it usually is here on sitepoint

[akrabat]

As I understand it, an Active Record is just a Row Data Gateway with some domain logic in it.

The fun and games start happening when dealing with the relationships to the row that's encapsulated in the AR...

[thr]

As I understand it, an Active Record is just a Row Data Gateway with some domain logic in it.

Correct.

The fun and games start happening when dealing with the relationships to the row that's encapsulated in the AR...

Yes, RDG <> AR is very alike, but I'd say that the fun(it's fun to write the mapping, true - but not fun when it makes performance hit rock bottom) starts going out when mapping relations as it's (often) very ineffective to map them instead of grab the ones you need like: $posts = $postGW->findByAuthor($author);

As I wrote above the problem is that either you're fetching to much or to little, both leading to performance issues when dealing with many requests / big requests.

[lftl]

No hand-written config files (if any are used, they should be automated), XML or any other format - No, propel requires .xml config files.

I'll say this point is open to a little interpretation. My interpretation is that Propel passes this point because it can reverse engineer its config file from an existing database. So yes, a config file has to be created, but it doesn't have to be by hand.

Usable out of the box, at least for the simple cases (e.g. for single PK tables with up to one FK, which are most common on Web) -- no need to write complex table-classes before using it - No, propel requires definition and building of your objects and relations, I'd hardly say that's "out of the box".

Again, up to interpretation of what is meant by out of the box. If defining the schema and compiling the om is beyond out the box behavior, then Propel doesn't really do anything out of the box. I definitely understand, that's more work than some want to go through to get it up and running, but it's not the definition I was going by when I made my comment.

[Dr Livingston]

> So yes, a config file has to be created, but it doesn't have to be by hand.

It could be automated but does Propel allow for that automation though? I'm not sure where Propel stands in that regards

[lftl]

> So yes, a config file has to be created, but it doesn't have to be by hand.

It could be automated but does Propel allow for that automation though?

Yes

[BerislavLopac]

If defining the schema and compiling the om is beyond out the box behavior, then Propel doesn't really do anything out of the box.

That was exactly my point. Essentially, I want ORM to be able to (at least for simple tables, and given an already created database) do something along these lines:

$table = new ORMTableWhatever('table_name');
$table->doTheMagic(); 

[thr]

Personally I prefer:

$table->doKungFuMagic(); 

On a more serious note I agree with BerislavLopec.

[lftl]

That was exactly my point. Essentially, I want ORM to be able to (at least for simple tables, and given an already created database) do something along these lines:

$table = new ORMTableWhatever('table_name');
$table->doTheMagic(); 

I suppose it's all a matter or preference. I personally don't mind doing the following for an already existing database with simple tables:

propel-gen creole; propel-gen om;

It would be cool if Propel just did that for me, but I've never found it particularly cumbersome.

[Luke Redpath]

The only thing I hate in both ZF's and RoR's AR, which apparently got accepted by the ADOdb's as well, is the convention that class names are singular and table names are plural. My personal convention is to view tables as entities, and thus I keep their names in singular as well. Maybe I'm weird that way, but I'd like that at least to be a modifiable setting.

Most things in Rails AR are overrideable, including the table name. In fact, I believe their is a setting that disables table pluralisation globally. Personally I think plurals are the perfect fit because tables are collections, rows are singular.

[Dr Livingston]

> but I'd like that at least to be a modifiable setting.

I don't see personally, that there is a problem, but besides you can use whatever convention you like with Zends framework - read the documentation

[michel]

I have never played with TableDataGateway. Someone care to provide some (pseudo) code examples?

[thr]

I have never played with TableDataGateway. Someone care to provide some (pseudo) code examples?

Basicly a Table Data Gateway is just that, a data gateway for your db tables. If you look at the Zend_Db_Table class you got a classic TDG example. A gateway encapsulates all behaviour regarding CRUD + Specialized Finders for one table in a database. Here's fowlers definition of a table data gateway http://martinfowler.com/eaaCatalog/t...taGateway.html

Fowler uses a separate Person object for the PersonGateway, Zend_Db_Table uses a general Zend_Db_Row class instead. I'd say that Fowlers version looks very much like a simplified mapper. You can also use TDGs as a backend to your datamappers to encapsulate sql logic in one place.