Great Daniel, thanks. And yes, I think that your diff may be useful... At least, I hope that using DbFinder, I will be able to write "ORM- compatible" code for Symfony's future versions (I will try to contribute in that direction as well)...
> first: I think Fabien was just kidding when he said "Then, use plain PDO." :) Sorry... a smiley could be useful next time... :-/ On 3 déc, 11:11, Daniel Lohse <[email protected]> wrote: > Hey there, > > first: I think Fabien was just kidding when he said "Then, use plain PDO." :) > > So, here's one for you. I have the DbFinderPlugin working (at least, kinda) > under symfony 1.4 (!). > If you want I can post a diff here. There's one thing I couldn't figure out > as of yet but that could be a problem in my own code. > (Explanation: after trying to fix a few snags in DbFinder I quickly tested my > application and one form didn't save to the db correctly. All the other > things worked like a charm. Sorry for not having unit tests, shame on me.) > > Obviously, when running the new project:validate task it will tell you that > there's deprecated code in DbFinderPlugin. but you are on the safe side if > you don't use the DbFinderAdminGenerator which was using deprecated symfony > 1.0 features anyway. If you do use this, you'd have to stick with symfony 1.3. > > Cheers, Daniel > > On 2009-12-03, at 3/December, 10:59 AM, Frosty wrote: > > > Fabien, > > > Thanks for your quick answer. > > >>> I don't mind if I work with Propel, Doctrine or > >>> AnyOtherSuperFutureORM. I just want it to query my DB. > >> You don't mind? Are you kidding? Then, use plain PDO. > > > Obviously, plain PDO does not offers the capability of an ORM. > > I would like to use ORM "standard capabilities" but without bothering > > which ORM I'm using (it's Symfony's business). > > >>> I shouldn't rewrite all queries and schemas if I need to switch ORM, > >>> just because Symfony developers changed their recommendation. > >> Why do you want to switch ORM? Both Propel and Doctrine are supported by > >> symfony. There is no need to switch to another ORM. > > > Doctrine is the default ORM since 1.3, and will be the only supported > > ORM from Symfony 2.0. Therefore, if you want to keep your projects up- > > to-date and benefit from the last Symfony features and LTS, you MUST > > use Doctrine. > > >>> I'd rather do something like : > >>> $results = Db->from('Article a')->join('Comment c')->where('...')->find > >>> () or ->paginate(...) > >>> whatever being the underlying ORM. > >> Then use Doctrine ;) > > > Using Doctrine syntax doesn't mean using Doctrine, if I need to use a > > different ORM (e.g. for performance issues). > > That's all the difference between DbQuery::create()->from(...) and > > DoctrineQuery::create()->from(...). > > IMO Symfony, like PHP, should stick with one syntax through each major > > version's lifetime. > > Instead, we still have ORM-dependent syntaxes. What if tomorrow we > > have to support "Rocks", "Redbean" or "LightORM" (or even a > > "Doctrine2" or "DoctrineFork") with their own syntaxes ? Each > > important plugin will have to be maintained to work for each > > frequently used ORM ? > > > BTW, don't you agree with that ? > > >>> A generic ORM layer in Symfony : > >>> - Avoids to create / update / read documentation for each new ORM > >>> (instead, work on one ORM abstraction layer) > >>> - Avoids to rewrite & relearn DB querying when switching ORM > >>> - Avoids to split the community with decisions such as > >>>http://www.symfony-project.org/blog/2009/06/11/new-in-symfony-1-3-wha... > >>> - Allows support for multiple ORMs > >>>http://en.wikipedia.org/wiki/List_of_object-relational_mapping_softwa... > >>> - Greatly improves plugin compatibility > > > Thanks. > > > On 2 déc, 19:15, Fabien Potencier <fabien.potenc...@symfony- > > project.com> wrote: > >> Frosty wrote: > >>> +1 for a DbFinderPlugin support for Symfony >= 1.3. > >>> I even think that such a piece of code should be part of Symfony core. > > >>> I don't mind if I work with Propel, Doctrine or > >>> AnyOtherSuperFutureORM. I just want it to query my DB. > > >> You don't mind? Are you kidding? Then, use plain PDO. > > >>> I shouldn't rewrite all queries and schemas if I need to switch ORM, > >>> just because Symfony developers changed their recommendation. > > >> Why do you want to switch ORM? Both Propel and Doctrine are supported by > >> symfony. There is no need to switch to another ORM. > > >>> I'd rather do something like : > >>> $results = Db->from('Article a')->join('Comment c')->where('...')->find > >>> () or ->paginate(...) > >>> whatever being the underlying ORM. > > >> Then use Doctrine ;) > > >>> If the ORM choice is not obvious (like for Propel & Doctrine), just > >>> support all the "best" ORMs and let the user choose through > >>> configuration if necessary... The default one being Symfony's > >>> recommendation. > > >> This is exactly what you have with symfony 1.3/1.4. 2 ORMs and your > >> choice when you start a new project. > > >>> Moreover, if you need a very specific and uncommon ORM feature, you > >>> could just configure Symfony to use that ORM and bypass the "generic > >>> layer", calling directly the ORM classes & methods. > > >>> The format for YML schemas and admin generation could be, as well, > >>> processed in a generic way through all future framework versions & > >>> ORMs. > > >>> A generic ORM layer in Symfony : > >>> - Avoids to create / update / read documentation for each new ORM > >>> (instead, work on one ORM abstraction layer) > >>> - Avoids to rewrite & relearn DB querying when switching ORM > >>> - Avoids to split the community with decisions such as > >>>http://www.symfony-project.org/blog/2009/06/11/new-in-symfony-1-3-wha... > >>> - Allows support for multiple ORMs > >>>http://en.wikipedia.org/wiki/List_of_object-relational_mapping_softwa... > >>> - Greatly improves plugin compatibility > > >>> IMHO all that worths the slight overhead generated by the generic ORM > >>> layer, which should be mainly rewriting method calls. > > >>> BTW, note that the same problem goes for email sending... > > >>> On 2 déc, 16:21, MoUeTtE <[email protected]> wrote: > >>>> thanks for answering, and of course each ORM has it's good parts. > > >>>> For sure specific data logic has to be developed directly using ORM, > >>>> and I never said we have to ban ORM specific dev nor that DbFinder has > >>>> to implement nested set or geocode behavior. I just find it's a pity > >>>> it is no more maintained. > >>>> In some cases such as newsletter, application preferences, template > >>>> switcher, even a simple blog, logic is very simple and it should be > >>>> possible to have it ORM agnostic. It's all about avoiding code > >>>> replication when it is possible, and DbFinder has been developed for > >>>> that. > > >>>> I really think a first class framework as symfony has to furnish such > >>>> a thing, that's all. > > >>> -- > > >>> You received this message because you are subscribed to the Google Groups > >>> "symfony users" 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 > >>> athttp://groups.google.com/group/symfony-users?hl=en. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "symfony users" 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 > > athttp://groups.google.com/group/symfony-users?hl=en. -- You received this message because you are subscribed to the Google Groups "symfony users" 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-users?hl=en.
