svil wrote: > is it errorneus to explicitly put the (correct) joins even if they > could be figured out by SA?
its not. but made your code that much harder to read (there was a lot more that made it even harder, thats just one cherry-picked example). > Two examples are the StaticType declarative structure "language" > (creatings python objects of unchangeable structure; very usable for > DBs, protocols and similar must-not-change stuff), i hear Java is good for that ;). and the expr.py, > which has a way to interpret python functions into Expr-trees, which > then can be translated (read code-generation) into whatever, like text > or sql-alchemy column expressions. are you using AST for this at least ? no need to reinvent the wheel.... > It's all like using the python to build _your_ syntax tree made of your > objects, and then use the objects - or some visitor - to do > code-generation/ interpretation. sounds awfully generic, when i could just write a little AST visitor... > > i really _really_ want to extend the SA to be able to automaticaly do > table-decomposition and mapping of an object-hierarchy. > As i said, think of activemapper that also does inheritance and > queries, provided just a few hints of how user exactly wants it done. well there is a project going on to produce the next gen. of activemapper and turboentity, and im sure they will add "inheritance" to it, since its pretty trivial. as far as querying, im guessing you are looking for an object-query-language (which is what all the "pure ORM" types seem to be desiring...but strangely they never get....) > > So, back to the question: inheritance and referencing together? > This is what stops me now; otherwise i have about 10 diff.cases that SA > goes wrong, but i've found a way around so don't bother about them > _now_. yeah...to be honest, i dont have the resources to debug an entire application, im in the business of maintaining and developing SQLAlchemy, and if theres a bug which you can illustrate with a *simple* test case of around 50 lines or less, ill fix the bug, or if theres some configuration based upon SA's *documented* usage patterns that doesnt make any sense, i can similarly illustrate how its done. reading the thousands of posts on the mailing list (including the old ones) as well as the tickets in trac can illustrate the kinds of examples that I can work with, without requiring my spending all day learning how someone's application works (because i cant spend all day, ive got paying work ive got to be doing). but if youre writing a whole big thing that is dynamically creating tables/classes which are then invalid, and it just doesnt work, thats kind of out of scope for me...just reading a single test case of yours takes me a very long time since they are not at all easy to follow...maybe some other folks on the list have some cycles to dig into the things that you are doing. you are getting SA exceptions which do have meaning and id suggest you dig in to SA itself to figure out what conditions might create those errors (such as various conflicting columns/properties seems to be a theme with what you have there). but if it turns out that youre doing something that is just wildly different from what SA's ORM basically does (such as its attribute instrumentation), im not sure if building on SA's ORM is your best bet...its already very high level and it is definitely going to be hard to build many more layers of class manipulation on top of it. you can always write your own ORM layer, feel free to borrow from SA's ORM concepts that you like and just use SA's SQL construction facilities to help you out. it might sound like a much bigger job but you would A. definitely learn SA's internals very well and B. get some deeper insight on the problems youre trying to tackle. > > Also, if u can fix that "repeating" return obj.__dict__[key] in > orm/attributes.py InstrumentedAttribute.get()... > to be just "return value", > will be great. line 214 or so. sure, changeset 2211. things like that, you should create a patch, then run the entire unittest suite to insure it doesnt break anything, then create a new ticket with the patch. also try to create distinct tickets for patches that address distinct issues. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
