ah. when u don't have an explicit spec, the testcases are the real spec. so make sure u really cover all them funny cases (-:
i had the default_values problem too, and to solve it i have split the attr.access into two layers: one that sits below SA (as a fake dict), and one thin that sits on top of it. First one handles basic stuff / data storage, latter does default_values and lazy-autosetting it (in terms of static_type/). Look for AutoSetter and related in dbcook/usage/static_type/sa2static.py There is subtle difference in whether the traits/descriptor will auto-set the default value or the SA/sql-server, make sure u understand it. First case SA/sql would never know about missing value. as of precedence... i have one declaration and i would not care who sets the vales as long it is what's in the declaration. you choose yours svilen On Wednesday 25 March 2009 14:47:35 Christiaan Putter wrote: > Hi, > > Right now I'm really only using multiple threads for speeding up > downloads over the internet (which I need to update the data). > Actually commiting the data is still done via the gui's thread > session. At some point speeding up the algorithms would be nice, a > concurrent solution would be ideal seeing as how the calculations > for each record are independent. Though I might look into RPC for > that instead to get actual speed ups. That will probably solve the > thread / session problem in any case. > > The unit testing has revealed some serious problems. Mainly todo > with traits and the declarative extension not knowing how to > cooperate (eg. traits provides a mechanism to set up default > values, though the instrumented attribute obviously overrides that > and returns what sql says it should). I really don't want to set > up the mapper from a class definition myself, declarative makes > that much simpler so i don't want to give up on that. So I'll have > to create my own intrumented attribute / traits subclass. Either a > trait that wraps an instrumented attribute, or an instrumented > attribute that wraps a trait. I need to somehow provide both > traits and SA with the functionality they need in a single > attribute on the instance. What do you think will be easiest? > > That of course raises the question of what should take precedence. > The value provided by traits or the one from the database. Or > whichever is not None. > > I'll look into the mapper extensions. > > I never thought some simple unit testing would cause so many > headaches :-) > > I'm talking to someone at enthought to maybe integrate that into > their sandbox for now. I'm sure once someone else with more > experience with the traits framework looks at it we'll be able to > figure out what the simplest way to use sql with traits would be. > And then the implementation should become clearer as well. > > Hope you're having a nice day, > Crhistian > > --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
