On 11/21/12, Remy Blank <remy.bl...@pobox.com> wrote:
> Olemis Lang wrote:
>> The ultimate goal would be to eliminate the current
>> dependency with hard-coded SQL queries based on current database
>> schema (i.e. things happening on top of DB connection abstraction layer,
>> but beneath Trac business logic layer) so that we could be able to
>> override
>> default implementation (i.e. current SQL queries) with our own
>> implementation .
>
> How do you plan to make sure the dozens of available plugins continue
> working after such a change?
>
Good question . The solution is a bit diifficult to explain in a
single e-mail message , and it is still being improved . That's why we
decided to write BEP 3 [1]_ in first place . I'd appreciate if you
please could read it , in order to get a better idea on what we are
trying to do beyond single environments proposal [2]_ .
>> PS: I know you have rejected the use of ORMs before , but this is
>> substantially different (... I guess ...) and IMO very important for us.
>
> That must have been before my time in Trac, but...
well, I recall discussions about not using ORMs and stick to SQL
queries understood by the vast majority of dialects instead .
> how is this
> substantially different?
>
well , ORMs API is highly influenced by the underlying DB schema and
SQL queries . DAO API may be designed considering business rules .
Indeed DAO methods may be implemented with the help of ORM frameworks
. I found [3] somewhere out there and this is a naïve comparison ,
hope you get the idea
;)
ORM:
q = OrmDbQuery()
q.select('u').from('User', 'u').where('u.id = ?1').orderBy('u.name', 'ASC');
...
DAO:
def get_something_I_want(...):
...
As you can see in the las case it is not necessary to know how the
underlying DB schema is designed but what business data is needed .
More or less that's the idea . Afterwards it would be possible to
implement such methods in many ways , and all the business logic on
top of it still will work even if data access layer turns out to be
completely different .
.. [1] BEP 3 : Multi-product architecture
(https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003)
.. [2] Multiple Projects within a Single Trac Environment
(http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment)
.. [3] Data Access Object (DAO) versus Object Relational Mapping (ORM)
(http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
