On Oct 12, 10:09 am, "Gaetan de Menten" <[EMAIL PROTECTED]> wrote:
> I couldn't agree more. I mean: shouldn't the "autoload" part be
> integrated into SQLAlchemy reflection capability if it can do more
> than SQLAlchemy 0.4 currently support (or simply removed if it doesn't
> do more)?
As i mentioned in my last reply I'll try to add support for sqlalchemy
0.4 in a 0.5 branch of autocode but will maintain an actively
supported 0.4.x branch.
I don't know how much of the features of autocode should really go
into sqlalchemy. Model generation tools should IMHO always stay a
separate part but I'm open for suggestions. I also hate code
duplication but I think that especially the formatter part should stay
outside of sqlalchemy: It has a strong relation to the autogeneration
of the model and as I've learned from my experience with other ORM
tools, such a feature is better to handle outside the main engine.
My plans:
+ Release a 0.4.1 with more stable formatting engine and a stable
interface with support for all databases where sqlalchemy 0.3.10 has
dialects for.
+ Start working on 0.5 with sqlalchemy 0.4 support
+ Include Firebird support
Everyone who is interested may join the project on googlecode and
contribute source code.
Simon
> On 10/11/07, Paul Johnston <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > It's really good to see this script progressing.
>
> > BTW, with SA 0.4, this script should be able to work with no
> > database-specific hacks at all. If you're interesting in implementing this,
> > I can explain more.
>
> > Paul
>
> --
> Gaëtan de Mentenhttp://openhex.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
