Announcing new model code generation tool: sqlacodegen

[Alex Grönholm]

After a while of trying to fix sqlautocode, I ended up writing a new tool instead.

Copypasta from the README:
---------------------------------------------

This is a tool that reads the structure of an existing database and generates the appropriate SQLAlchemy model code, using the declarative style if possible.

Features

• Supports SQLAlchemy 0.6.x - 0.8.x
• Produces declarative code that almost looks like it was hand written
• Produces PEP 8 compliant code
• Accurately determines relationships, including many-to-many, one-to-one
• Excellent test coverage

---------------------------------------------

It should work at least as well as sqlautocode. There is some room for future improvement, of course:

• Autodetection of joined-table inheritance
• Code generation for separate tables/classes/mappers instead of declarative
  
• Proper code generation for deferred/immediate foreign key constraints
• Sorting out problems with CheckConstraints (there seems to be a problem outside of sqlacodegen here)
  

[Alex Grönholm]

Forgot to add the link: https://pypi.python.org/pypi/sqlacodegen

[Chris Withers]

On 18/05/2013 01:28, Alex Gr�nholm wrote:
> This is a tool that reads the structure of an existing database and
> generates the appropriate SQLAlchemy model code, using the declarative
> style if possible.

Playing devils advocate to get my head around this: why would you want
to generate code when you could just reflect the models?

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk

[Alex Grönholm]

18.05.2013 12:35, Chris Withers kirjoitti:

On 18/05/2013 01:28, Alex Grönholm wrote:

This is a tool that reads the structure of an existing database and
generates the appropriate SQLAlchemy model code, using the declarative
style if possible.

Playing devils advocate to get my head around this: why would you want to generate code when you could just reflect the models?

Chris

I can think of a number of reasons:

• You'll have to write the classes manually otherwise (save for the column defs if you use reflection)
  
• Reflection won't give you relationships -- you'd have to add them manually anyway
• Reflection takes time and will slow down application startup, especially with large schemas
• Automatic generation of schema migration scripts will not work unless you have a model that differs from the actual schema
  
• You may need static analysis of the code

The more complex your schema is, the more useful automatic code generation will be for you. Of course, if you only do metadata reflection and don't use declarative, well, that's another matter. But most people want mapped classes to use in their apps.