Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olemis@gmail.com designates
 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <87c86dfa-cba6-40ef-93d2-ab01b8942656@googlegroups.com>
References: 
 <CALZVap=16qxQ25SccJ447AkaLabw_w4fTx1CLB3x1uttvzQoDw@mail.gmail.com>
	<e8441b82-e043-4622-b760-9ea03d3dd2e1@googlegroups.com>
	<C61D81F2-0F09-45F1-9913-7A18011CF2D9@inquant.de>
	<87c86dfa-cba6-40ef-93d2-ab01b8942656@googlegroups.com>
Date: Tue, 5 Mar 2013 16:47:37 -0500
Message-ID: 
 <CAGMZAuORUMjNFve2VPV=-gGmLxFxxEatCmrbs8GRJhhebFy+Bw@mail.gmail.com>
Subject: Re: [Trac-dev] Re: Trac internals' database simplification
From: Olemis Lang <olemis@gmail.com>
To: trac-dev@googlegroups.com
Cc: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

cross-posting to blodhound-dev ML fyi . Please follow in trac-dev@...

On 3/5/13, Leho Kraav <leho@kraav.com> wrote:
>
>
>> + 1 for creating/adding a
>> DAL to Trac
>>

+1

>> I could imagine that doing a fundraising for the goal could raise some
>> money
>> for solving the human ressource problem.
>>

Just count me in
:)

IMO the following two major scenarios would have been much easier to
handle if an ORM would be handy :

  1. mult-product support
  2. run Trac with NoSQL DBs (e.g. MongoDB , CouchDB, ... )

so IMO it's about time to get rid of the SQL dependency .

JFTR we are using a kind of hand made ORM in Bloodhound and there's
also a way to make plugins use SQLAlchemy (plugin available @ t.h.o) .
We didn't move forward to using ORMs , DAO or such kinds of DAL
because Trac didn't in first place and it was very important for us
(at the time) to keep our core compatible with Trac's . So we
translated SQL queries under the hood , and so far looking good ...
;)

>>
> Maybe. Noone has attempted that yet.

We have . Before starting Bloodhound multi-product support we raised a
request in trac-dev (just take a look in ML archives if not already
deleted) focusing on two options :

  1. using DAO pattern
  2. use ORM technologies

there was no actual useful response from trac-dev , so we decided to
go our own way

[...]
> But Hans, which direction are you preferring. Porting Trac main modules -=
>
> let's say Django, or hack Trac's core framework up towards the giants.
>

I'd advocate using the second . Let's just choose the ORM ;)

> My spidey sense is telling me world doesn't really need yet another web
> framework. I think it would make (at least for business) sense to port th=
e
> modules on top of bigger frameworks.
>

-1
The foundations of Trac are rock solid .

--=20
Regards,

Olemis.

Apache=99 Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: