Why Propel way ?

[Christophe Willemsen]

This post as answer to @bazinder on Twitter.

1. Using cache proxies, good. But afaik cache is for optimization, not for something to rely on.

2. The entity manager, well it has advantages to have a central point but at the end this is chocolate, what are the real advantages of using a manager ?

3. in propel, queries are optimized by model, not globally

4. everything is overwritable, you can really do specific optimizations. what if you want to do a custom query for a timestampable property of a specific model with doctrine ?

5. most important related with cache, with propel your business classes are created during development, not during runtime

6. let's say, doctrine is the most well written and elegant orm, propel is the best performance orm

Don't hesitate to argue on my thoughts

Cheers

Christophe

[Louis-Philippe Huberdeau]

Hello,

The reason I went for Doctrine-style is that the direct entities can be instantiated and tested against without having to rely on the database at all. I personally find it cleaner than to use inheritance.

Second, the purpose of proxies is not for cache and performance. In the early versions of the OGM, I used a decorating proxy class that did not rely on class generation. Everything ran just fine, up until the point I got to integrate the objects within views, and then Twig would reject almost everything. Twig, and many other components around symfony, rely heavily on reflection to figure out what needs to be done, and this is why I switched to generating classes and replicating the exact interfaces to include my just-in-time loading logic.

This transition was done without major changes to the test suite as the tests only relied on very little knowledge of the way the entity manager works. This is the beauty of Doctrine.

I don't know if the performance/optimization argument is as valid in Neo4j as it is in relational databases. I don't really know if it's relevant for relational databases either. I can't say I used Doctrine2 on very heavy load, but I never felt it had a weight too heavy to support, or that the issues were fundamental. I've loaded thousands of nodes in Neo4j using the OGM through Neo4jphp and ran extensive profiling on it. I found a few issues, but most of the time ends up being spent on HTTP requests to the server.

--
LP

Christophe

--
 
 

[Christophe Willemsen]

I appreciate your feedback LP, btw I hope it's now ok with your house.

To keep up certain points, I do not say doctrine is bad it is just using some concepts that when you come to specific optimization, sometimes you need to override too much part of the doctrine logic.

For what proxy matters, i did not say it was made for cache, but only that the cache in my opinion is not for having the base models logic.

As I said also on IRC, I think it's also important to keep your doctrine implementation, I will surely use it on a time, currently I just want try with the propel way and yaml schema to see if it can be suited in dev.

Keeping your lib is as important as trying out new things, most of the symfony users are using doctrine, so it will be easier to make the transition to a graph db without loosing the doctrine habits.

Cheers,

Good weekend,

Chris

[Martin Bažík]

i took a quick look at propel and i would say it implements the active record pattern which is nowadays considered to be an anti pattern. i haven't gone into the details but what i can seen in all the examples is that every entity implements the method save which in my opinion shouldn't be tere at all as it has noothing to do with the business logic.

On Friday, September 14, 2012 8:21:45 PM UTC+2, Christophe Willemsen wrote:

For what proxy matters, i did not say it was made for cache, but only that the cache in my opinion is not for having the base models logic.

i have used either doctrine orm or odm for the past 2 years and all the business logic is always in the entity or document classes. there is no boilerplate code so these classes don't need to extend any base class. proxies are used just for lazy loading. i never had to overload any default behaviour and i've been building pretty complex systems.

annotations help keep the code readable and you have all the mapping information in one file, unlike with mappings definitions somewhere in yaml files.

if you classes like these, it is then quite easy to change the persistence layer, as the logic and entity management is separated. 

it's also better testable as LP has said. altough it may be more explicit than active record, the work of unit makes it very efficient when saving many documents at once. so far i've found it very pleasable to work with and i wouldn't change for anything else.

when some cache like apc is used to hold the parsed mapping metadata the performance doesnt suffer.

so i consider the doctrine style the cleanest approach and would be very happy to see the ogm reworked to converge with other doctrine mappers than develop a new one which builts on a deprecated approach.

p.s.: i'm bazinder on twitter

[Christophe Willemsen]

* I would also be very happy to see the ogm in the future, it is already wide used iaw packagist stats.

* propel does not use active record, but more model driven architecture. i recommend you these slides http://williamdurand.fr/2012/06/08/introduction-to-propel2-at-symfony-live-2012/ . inheritance will be removed with propel2.

  btw propel is used in symfony via the bridge, is used by Sensiolabs and TF1 for e.g so I don't think such frameworks and companies use deprecated approaches.

* I use doctrine orm on daily basis also, but I just think the requirements that a graph db have would be better handled with something that start from scratch and is not constrained in scope.

BTW I will continue to commit on the ogm, I don't just currently use it. People are free in choice and matters of taste.

Cheers ;)

[Martin Bažík]

it was really just a quick look. i was scared by the save function. if your lib will suport the spatial features then i will use it for sure :)

Dňa sobota, 15. septembra 2012 17:48:35 UTC+2 Christophe Willemsen napísal(-a):