"BrendanC" <[EMAIL PROTECTED]> writes: > New user here trying to get started - I'd like to create an ORM map from an > existing legacy (SQL Server) database - although I may convert this to > Postgres or MySQL. > > So what is the least painful approach to creating the ORM (I plan to > use TurboGears to create some Web Front End screens to this database.)
The least painful approach depends on "when". If you're talking about getting it running *now*, then making the ORM load the definitions from the database is the fastest way. If you're talking about migrating, then describing the database correctly in your model is the least painful approach because you'll have all the work *now*, but your application will be already changed and your model will be able to recreate the tables as needed, so you won't have to worry with it later. > Most of the ORM docs I've read seem to require that the schema be > defined in the ORM tool - however for a large legacy db that seems > like a lot of work. I'd like to reverse engineer the db and create/ > derive the maps/relationships from the SQL catalog - Is this possible? > Am I missing something obvious here? > > More specifically, can I reverse migrate (??terminology??) from an existing > production database and have all the foreign keys/database constraints/table > relationships recognized and get models and controllers generated correctly? The term is the one you used on the first paragraph above: reverse engineer. Even though the ORM can reverse engineer your database some complex constructions might need some help from you. So you don't need to declare every table, but you might need to declare some of them. There's nothing that I know that will generate controllers from a database schema. So you'll have to write those by hand. There are CRUD tools, though, that might help a lot with basic functionality. > I'd like to avoid any hand coding (e.g. tweaking FKs/relationships) as part > of this initial migration. It all depends on your database schema, how complex it is, how normalized it is, etc. If there was a good normalization project, things get easier for reverse engineering tools (including SQL Alchemy). > Any links to relevant ref materials/tutorials/etc would be appreciated here. There are docs on the website. They help a lot! -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
