[sqlalchemy] Re: extending pre-existing tables
On Nov 10, 2008, at 3:42 PM, [EMAIL PROTECTED] wrote: Right now I'm playing with mapper inheritance. The first stumbling block I've come to is the case where the local table doesn't yet have a row for the object from the base table. In that case, a query on my subclassed object returns nothing. Do I need to write an import program that creates rows in the local tables for any items in the imported data that don't yet have them? That strikes me as rather fragile. Is there a way to automate the creation of the local table row with default values? using table inheritance implies that for a subclass such as ExtendedFoo, both tables are populated at all times. So yes you'd have to work out some way to ensure that the database is in the state required to use SQLAs table inheritance functionality. The system you're using to populate the base tables would need to be extended in this way. Or am I approaching this all wrong? Possibly. The fragility here is that you are relying on a model that isn't actually implemented here, i.e. that your application is written around a table inheritance assumption when that is not actually the case - the extended tables may or may not have a row present for a corresponding base row. It would likely be more straightforward to implement a non-inheriting system. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: extending pre-existing tables
On Mon, 10 Nov 2008 at 17:19, Michael Bayer wrote: Possibly. The fragility here is that you are relying on a model that isn't actually implemented here, i.e. that your application is written around a table inheritance assumption when that is not actually the case - the extended tables may or may not have a row present for a corresponding base row. It would likely be more straightforward to implement a non-inheriting system. OK. Is there a way to do that and still have the (for example) ExtendedPublication object inherit from the Publication object, or do I need to switch to an object composition scheme? In which case pre-populating the extended tables may be a lot easier :) --RDM --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: extending pre-existing tables
On Nov 10, 2008, at 5:34 PM, [EMAIL PROTECTED] wrote: On Mon, 10 Nov 2008 at 17:19, Michael Bayer wrote: Possibly. The fragility here is that you are relying on a model that isn't actually implemented here, i.e. that your application is written around a table inheritance assumption when that is not actually the case - the extended tables may or may not have a row present for a corresponding base row. It would likely be more straightforward to implement a non-inheriting system. OK. Is there a way to do that and still have the (for example) ExtendedPublication object inherit from the Publication object, or do I need to switch to an object composition scheme? In which case pre-populating the extended tables may be a lot easier :) you should go with composition since its simpler. After that, if there's something missing that inheritance provides we can take a look at that. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
