On 12.10.2007, at 18:46, Gaetan de Menten wrote:
On 10/12/07, Simon Pamies [EMAIL PROTECTED] wrote:
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
On 12.10.2007, at 18:56, Paul Johnston wrote:
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.
Would be nice to hear more details about this.
With 0.4, dialects have a
2007/10/12, John M Camara [EMAIL PROTECTED]:
I performed a release under LGPL. Hope that this is ok and fits into
the sqlalchemy environment.
Why not just release it under MIT like SQLAlchemy? The project will
likely receive wider use under MIT rather than LGPL.
+1 on the MIT licence
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)?
And I fact, I think the formatting part could also be integrated into
SQLALchemy
Hi,
I don't say that everything should be integrated, just the reflection
part (if at all useful in SA0.4) and the repr methods of the
corresponding objects (*_repr in formatter.py) which should IMHO
replace the current repr methods.
That sounds good. One consideration is that autocode repr
On Oct 11, 11:10 am, Werner F. Bruhin [EMAIL PROTECTED] wrote:
I had changed one of the other versions to handle Firebird and got it to
work for my purposes, but did some hacks which were not for public
consumption.
If you or someone else can help me working the hacks out then maybe
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
2007/10/12, Simon Pamies [EMAIL PROTECTED]:
On Oct 12, 2:48 am, John M Camara [EMAIL PROTECTED] wrote:
I performed a release under LGPL. Hope that this is ok and fits into
the sqlalchemy environment.
Why not just release it under MIT like SQLAlchemy? The project will
likely receive
On Oct 11, 2:21 pm, Paul Johnston [EMAIL PROTECTED] wrote:
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.
Would be nice to hear more details about this.
Currently I'm stuck to
Hi,
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.
Would be nice to hear more details about this.
With 0.4, dialects have a table_names() method that will do the job of
On Oct 12, 2:48 am, John M Camara [EMAIL PROTECTED] wrote:
I performed a release under LGPL. Hope that this is ok and fits into
the sqlalchemy environment.
Why not just release it under MIT like SQLAlchemy? The project will
likely receive wider use under MIT rather than LGPL.
Can you
Simon,
Simon Pamies wrote:
Hi,
although I said I would start on Friday if there are no objections, I
couldn't longer resist to revamp autocode and so I moved it to google
code.
Please have a look at http://code.google.com/p/sqlautocode/ for the
changes and the current structure.
I also
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
--~--~-~--~~~---~--~~
You received this message
I performed a release under LGPL. Hope that this is ok and fits into
the sqlalchemy environment.
Why not just release it under MIT like SQLAlchemy? The project will
likely receive wider use under MIT rather than LGPL.
--~--~-~--~~~---~--~~
You received this
14 matches
Mail list logo
