Hi everybody.

Since Johannes brought up the fact that abstracted bundles become 
complicated, maybe I'll continue a little bit.

But first I'd like to thank everybody for a very insightful discussion. I'm 
not a merited Symfony developer in any way but I'd still like to bring some 
'views from the field' to your attention. We've been using Symfony2 since 
the release of 2.0 in our company and the topic of db abstraction is very 
relevant at the moment also in our team. So this post is more about the 
whole problem of creating database agnostic bundles, not so much about the 
naming convention stuff also discussed in this thread.

So why is db abstraction more relavant than 'the other stuff' just now for 
us? One of our important strategical approaches is to try to develop as 
many so-called 'generic' bundles or libraries as possible. These generic 
bundles (such as commens, shares, liking, polls, filestorage etc.) could be 
used in dozens of different websites with the help of concepts like bundle 
inheritance, distributed repositories and such. This is, of course, not an 
unique idea. Actually it seems it's more or less one of the core ideas of 
the whole Symfony. Many existing high quality open source bundles (e.g. 
FOSUser) support this idea too. The actual work of creating generic 
bundles, however, has proven to be very difficult and, more importantly, 
too time consuming. The main reason for this is the rule that a generic 
bundle should be database agnostic. And at the moment, writing db agnostic 
code in Symfony2 means writing dozens of factory classes to handle all 
possible repository implementations (as mentioned also earlier in this 
thread).

>From developer point of view, it's been quite obvious that Doctrine has 
been the defacto DBA technology in Symfony2. So just to be safe, we chose 
to use Doctrine too. The problem is, that Doctrine does not really promise 
any kind of consistency between ORM and ODM interfaces. This can be seen 
very easily just by looking at query building apis of Doctrine ORM and ODM. 
For us this is very problematic because MySQL and MongoDB are practically 
equally relevant databases and it cannot be assumed that generic bundles 
are binded to either of them.

So, what to do... I've been pondering this idea about whether there should 
be a super-generic DBA layer on top of everything else (yes, I know, 
everyone else has thought it too :)... But anyway, the idea behind this is 
that 95% of queries in practical websoftware are relatively simple. These 
do not require any database spesific features (even between relational and 
document storages). Also basic CRUD operations for an object are possible 
to implement identically for all databases quite easily.

To allow building true generic bundles easily (and rapidly) the generic DBA 
should fulfill at least following requirements:
- Lowest common denominator between all databases. Meaning, only features 
that are available in every database should be available in DBA.
- Absolutely consistent api. This can be achieved using similar abstract 
interface + adapter approach like e.g. in Gaufrette file storage library 
(which I very much like)
- Simple but flexible enough querybuilder for fetching data in 
objects/json/assoc arrays using a cursor for looping (or something).

Of course I could just try to create this kind of a piece of software 
(actually, we have some code from pre-Symfony life to handle MySQL and 
MongoDB already). However, if this abstraction would be provided with 
Symfony distribution, all 3rd party developers could trust that bundles 
created using this DBA would be generic enough to be really called 
"generic". Of course, for more complex use cases, this would not remove the 
need for db specific code but at least it would ensure that only difficult 
stuff has to be done per database. 

Finally, I know that Fabpot and others have stated that Symfony does not 
want to promote any Model-level solution. But still, the everyday life 
shows that some smart solution would be needed badly.

ps. If someone thinks that all that I'm saying could be done with some 
existing technology, please let me know about it. I've been looking without 
success.

Cheers,
Tomi

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to