|
List Info
Thread: Using the SQLAlchemy branch ?
|
|
| Using the SQLAlchemy branch ? |

|
2006-08-31 10:40:01 |
Hi
We're using Trac as a base too build our own internal
project management
and CRM tool. This leads me to developping plugins that are
more and
more real applications, and the Q&D ORM I built on top
of Trac's Db
layer starts to show it's limitations. SQLAlchemy would
obviously be a
far better tool here, and since Trac is to move to it, I've
been
thinking of trashing my own code and go with the
sandbox/SQLAlchemy
branch instead. OTOH, this would imply either maintaining
compat of this
branch with the trunk, which may or may not be a PITA...
Any thought, comment or advice on this ?
TIA
--
bruno desthuilliers
développeur
bruno modulix.org
http://www.modulix.com
_______________________________________________
Trac-dev mailing list
Trac-dev lists.edgewall.com
h
ttp://lists.edgewall.com/mailman/listinfo/trac-dev
|
|
| Using the SQLAlchemy branch ? |

|
2006-08-31 15:05:28 |
On Thu, 2006-08-31 at 12:40 +0200, Bruno Desthuilliers
wrote:
> We're using Trac as a base too build our own internal
project management
> and CRM tool. This leads me to developping plugins that
are more and
> more real applications, and the Q&D ORM I built on
top of Trac's Db
> layer starts to show it's limitations. SQLAlchemy
would obviously be a
> far better tool here, and since Trac is to move to it,
I've been
> thinking of trashing my own code and go with the
sandbox/SQLAlchemy
> branch instead. OTOH, this would imply either
maintaining compat of this
> branch with the trunk, which may or may not be a
PITA...
Right now I don't recommend using the branch. I'll get it
synced up
with the trunk soon, but it'll need some work before it's
really usable
for developing plugins on top of. SQLAlchemy is currently
integrated
for table creation, but not so much for general use. Stay
tuned as I
should be resuming work on that branch shortly.
--
Matt Good <trac matt-good.net>
_______________________________________________
Trac-dev mailing list
Trac-dev lists.edgewall.com
h
ttp://lists.edgewall.com/mailman/listinfo/trac-dev
|
|
| Using the SQLAlchemy branch ? |

|
2006-08-31 15:37:49 |
Matt Good wrote:
> On Thu, 2006-08-31 at 12:40 +0200, Bruno Desthuilliers
wrote:
>
>> We're using Trac as a base too build our own
internal project management
>> and CRM tool. This leads me to developping plugins
that are more and
>> more real applications, and the Q&D ORM I built
on top of Trac's Db
>> layer starts to show it's limitations. SQLAlchemy
would obviously be a
>> far better tool here, and since Trac is to move to
it, I've been
>> thinking of trashing my own code and go with the
sandbox/SQLAlchemy
>> branch instead. OTOH, this would imply either
maintaining compat of this
>> branch with the trunk, which may or may not be a
PITA...
>>
>
> Right now I don't recommend using the branch. I'll
get it synced up
> with the trunk soon, but it'll need some work before
it's really usable
> for developing plugins on top of. SQLAlchemy is
currently integrated
> for table creation, but not so much for general use.
Stay tuned as I
> should be resuming work on that branch shortly.
>
Do you have any idea if using SQLAlchemy could actually help
for our
"database locks" issues we're seeing with
SQLite? In particular, in the
light of what I wrote in #3446 [1], will it provide:
- the possibility to have very short-lived read
transactions
- the possibility to have replayable write transactions
-- Christian
[1] http:/
/trac.edgewall.org/ticket/3446#comment:4
_______________________________________________
Trac-dev mailing list
Trac-dev lists.edgewall.com
h
ttp://lists.edgewall.com/mailman/listinfo/trac-dev
|
|
| Using the SQLAlchemy branch ? |

|
2006-08-31 17:38:15 |
Matt Good wrote:
> On Thu, 2006-08-31 at 12:40 +0200, Bruno Desthuilliers
wrote:
>> We're using Trac as a base too build our own
internal project management
>> and CRM tool. This leads me to developping plugins
that are more and
>> more real applications, and the Q&D ORM I built
on top of Trac's Db
>> layer starts to show it's limitations. SQLAlchemy
would obviously be a
>> far better tool here, and since Trac is to move to
it, I've been
>> thinking of trashing my own code and go with the
sandbox/SQLAlchemy
>> branch instead. OTOH, this would imply either
maintaining compat of this
>> branch with the trunk, which may or may not be a
PITA...
>
> Right now I don't recommend using the branch. I'll
get it synced up
> with the trunk soon, but it'll need some work before
it's really usable
> for developing plugins on top of.
>
> SQLAlchemy is currently integrated
> for table creation, but not so much for general use.
Stay tuned as I
> should be resuming work on that branch shortly.
Mmm... Been playing with it (the SA branch) this afternoon,
and while it
seems possible to do more than just creating tables,
there's effectively
more to be done to really integrate SQLAlchemy... May I be
of some help
here ?
--
bruno desthuilliers
développeur
bruno modulix.org
http://www.modulix.com
_______________________________________________
Trac-dev mailing list
Trac-dev lists.edgewall.com
h
ttp://lists.edgewall.com/mailman/listinfo/trac-dev
|
|
[1-4]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|