[sqlalchemy] Re: FYI: AutoCode moved to a new repository

[Simon Pamies]

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

do more)?

than SQLAlchemy 0.4 currently support (or simply removed if it doesn't

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

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.

As i mentioned in my last reply I'll try to add support for sqlalchemy duplication but I think that especially the formatter part should stay

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. Or, to say that differently, I don't
see the point of having a repr method which doesn't produce a ready to
use string representation of the object if it's possible to do. That's
what the __repr__ method is for. And here, it's obviously possible
since you guys do it.

Simon

Sounds reasonable to me (after some thinking and realizing that repr can generate database independent code). But this decision will not be taken by me. I'll try to do the following: Provide stable and well designed repr methods (currently the formatter has some rough edges) and it'll be up to Michael to decide if he wants that in sqlalchemy core.

PGP.sig
Description: This is a digitally signed message part