On Jul 25, 2007, at 4:57 AM, Anton V. Belyaev wrote:
> > I believe this should be done somehow automatically. Because everyone > needs this. There should be two separate disjoint options: > > 1) Autoload, when working with previously created database for rapid > start. Columns arent specified at all in Python code (SQLAlchemy). we do it > 2) Tables are specified in the code. Database tables might already > exist and might not. And when issuing create_all(), all the situations > should be handled correctly: > 2a) If tables exist in DB and match Python-defined, ok. we do it (minus the "matching" part) > 2b) If tables do not exist in DB they are created, ok. we do it > 2c) If tables exist in DB and there is mismatch with Python-defined, > an exception is raised. new feature. however, a lot of people wouldnt use this feature. For one, its not a requirement that a Table object match whats in the database. its often the case that the Table does not define every column in the DB, or has different types, or is representing a view, etc. Secondly, reflection of a table is a big performance hit and not everyone wants that hit at the start of their appication or at the start of each child process. Thirdly, people also may be serializing their Table constructs in pickled files or similar so that the reflection step can be bypassed, thus increasing performance. To me its a "nice to have" but in practice it would probably get in the way more often than not if it was "always on". > >> but why not just use autoload=True across the board in the first >> place and eliminate the chance of any errors ? > > 1) I dont know if tables exist. I might need to create them. that implies youve already defined explcit Colums in your Tables; reflection is not needed in this case (except for this "verify the table" feature). > 2) When they exist, autoloading them might cause inconsistency with > SQLAlchemy-defined tables in sources. This is exactly what I am trying > to avoid. again, im not opposed to this feature and ill patch in an adequate (and fully unit-tested) implementation. but have you actually ever *had* this problem? or is it just hypothetical ? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
