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-what-s-up-with-propel-and-doctrine
> - Allows support for multiple ORMs
> http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP
> - 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 <the.moue...@gmail.com> 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 symfony-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> symfony-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 symfony-us...@googlegroups.com.
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en.
