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 at
http://groups.google.com/group/symfony-users?hl=en.
