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 <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
>>> 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 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.
