On Mon, Apr 4, 2011 at 7:08 PM, Chris Withers <[email protected]>wrote:
> On 23/03/2011 09:14, lars van gemerden wrote: > >> - I want to generate classes/tables based on metadata in another >> table in the database, filled by "designers" not programmers. >> > > Then you should be creating Tables and Mappers, not attempting to use > Declarative. I've had a closer look, can you explain what I can do with Tables en Mappers, that I cannot with Declarative or otherwise what the advantage can be? > > > - Multiple inheritance (from the designer perspective) provides >> flexibility in contracts ~ data attributes an object is sure to >> provide. >> > > I don't know what this means, please explain. OK, bit vague, so say we have classes A, B and C(A,B) multiple inheriting from A and B. Say also that A has members a1 and a2 (A adheres to a contract saying it can provide a1 and a2) and B has b1 and b2. We can then give an object of type C to methods built to handle objects of type A (expecting a1 and a2) *and *to methods built to handle objects of type B (expecting b1 and b2) . E.g. a "print" method might expect formatting attributes, while a "save" method might expect a file type attribute. Forget about the designer perspective, it even confuses me now ... :-) > > > - The diamond problem would complicate matters too much for >> > > I don't know what "the diamond problem" this, please explain. > > http://en.wikipedia.org/wiki/Diamond_problem: not really a problem, but added complexity that most likely will go past the sweet spot between simplicity and power for my use case. > > - SQLalchemy does not provide multiple inheritance (just single) out >> of the box, as far as i have been able to figure out. >> > > Did you look at Table Inheritance? > I think for your needs that Declarative is a confusing distraction. > I'd avoid it... I did, it seems to have pretty good support for single inheritance, but not for multiple inheritance. I haven't seen a way to adapt it (and Michael Bayer didn't seem to either without a lot of complexity ... :-( ) > > > There are more requirements, like in the end having (persistent) objects >> that still work like python classes for basic programming. >> > > Yep, sounds like tables, model classes and mappers to bridge the two to > me... > > > Not all problems can be solved with a simplistix approach ;-). >> > > The Simplistix approach has always been to find the simplest solution that > solves all the requirements. You still appear to be going in for an > extremely complex solution to a problem you don't fully understand... I definitively want too avoid any unnecessary complexity (i go through my code for clean-up cycles with increasing understanding of the subject at hand). Coming more from the OO side then the DB side, declarative just felt more intuitive to start with. It also seems to mesh better with metaclasses and since I need to generate tables/classes that are unknown before run time .... Any way, thanks for the feed back. There are some Mapper configurations that interest me, but I don't quite get them yet. Cheers, Lars > > cheers, > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > -- ==================================== Lars van Gemerden [email protected] +31 6 26 88 55 39 ==================================== -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
