|SQLAHelper status||Mike Orr||5/15/12 9:32 PM|
I put a notice in the SQLAHelper README that it's under a maintenance
freeze. I merged a patch by aodag and there's code in the repository
for a streamlined version 2 API, but with so few people using it I'm
not motivated to make a release. If anyone wants to take over
maintenance of it you can speak up here and talk to Chris McDonough
about write permission.
There's been some vague talk about a second Pylons Github project for
unofficial contributed packages, now that the Pyramid section has
accumulated over fifty packages and some are semi-obsolete. If the
second section comes to be, SQLAHelper and pyramid_handlers should
probably be moved to it.
Mike Orr <slugg...@gmail.com>
|Re: SQLAHelper status||erilem||5/15/12 10:45 PM|
Did this patch make it into the “version 1” branch? If so would it make sense to make a bug fix release?
FWIW, we still use SQLAHelper here, but I guess we could quite easily drop it. We still have like module interdependency issues but I guess this is bad design on our side.
Thanks for the notice.
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail : eric.l...@camptocamp.com
|Re: SQLAHelper status||aodag||5/16/12 3:18 AM|
That fix is to 2.0 branch.
Also that can apply to 1.0, but this fix changes behavior of ``add_engine``, so I don't.
I'm using sqlahelper heavyly, and I'v expected 2.0 release too.
Thus, I gonna maintain sqlahelper.
Can I get permission, move to pyramid-collective?
2012年5月16日水曜日 Eric Lemoine eric.l...@camptocamp.com:
Mail : firstname.lastname@example.org
|Re: SQLAHelper status||Jonathan Vanasco||5/16/12 7:56 AM|
i've been experimented with a replacement for a few months:
it does what sqlahelper does, but is rewritten quite a bit ( and
experimental ) to get the following done:
- reflect tables
- support multiple database connections
it seems to work correctly right now, but i don't have it on anything
|Re: SQLAHelper status||Mike Orr||5/16/12 11:42 AM|
Oh, the second project already exists.
I've submitted a pull request to create a SQLAHelper repository. When
it's ready I'll upload the existing repository to it, and then you can
add yourself as an owner and I'll delete the repository in Pyramid.
>> Mail : eric.l...@camptocamp.com
>> http://www.camptocamp.com>> To post to this group, send email to pylons-...@googlegroups.com.
>> To unsubscribe from this group, send email to>> pylons-discus...@googlegroups.com.
>> For more options, visit this group at
> --> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to> pylons-discus...@googlegroups.com.
> For more options, visit this group atMike Orr <slugg...@gmail.com>
|Re: SQLAHelper status||Mike Orr||5/16/12 12:59 PM|
On Tue, May 15, 2012 at 10:45 PM, Eric LemoineThere's only one branch, 'master'. Version 1 is the 'v1.0' tag. The
next maintainer can make a version 1 branch from that if he wishes.
You could put the Session and Base in a 'meta' module that is not a
parent of the other model modules and does not import them, as Pylons
The Pyramid default just puts them in the top level in the model. This
sometimes works and sometimes doesn't, depending on what other global
code is in your modules and whether it's above or below the import
If you do stick with SQLAHelper I'd suggest using the version 2 API,
which is more straightforward and has fewer getters/setters.
Mike Orr <slugg...@gmail.com>
|Re: SQLAHelper status||erilem||5/16/12 1:04 PM|
|Re: SQLAHelper status||aodag||5/16/12 4:03 PM|