let me think about it. as i see it u want to have runtime-invented data-only extensions to some object - or is it data + some algo about it? would the algos be new and reside in the new thing or they're just there and used?
imo this should be done via joins ala pyprotocols; inheritance is more about constant structures while u want same base object to grow and grow. i think SA.query(A,B1,B2,...).join(A.b1).join(A.b2)... gives u such notion (amde as A.b1 pointing to B1 etc) - try? u'll get tuples of (A,B1,B2,B3...) objects there hmm, one suggestion - try doing all this while forgetting about traits and meta-stuff first. once u get the dynamic=structure persistency working, add meta-stuff on top. ciao svil On Sunday 22 March 2009 23:31:49 Christiaan Putter wrote: > Hi, > > Maybe some better explanation is required from my side for you to > be able to help me better. > > My app is basically for doing some plotting, analysis and filtering > of securities on the stock market. > > The main class that does most of the work is > Security(HasTraitsORM), where HasTraitsORM is my version of > declarative's Base class which takes care of turning traits > (attributes) into correctly typed Columns for declarative to set up > the mapping. > > The Security class also handles retrieving historical data from an > hdf5 file which in my opinion is better suited to storing such data > in an hierarchical structure (with added transparent compression). > > SQLAlchemy comes into the picture for running queries mostly. And > storing precomputed values. > > For instance, using the above setup, I can add a child class > SMAFields at runtime which computes some simple moving averages of > closing prices. Once computed this gets stored in its own table > with columns sma10, sma20, sma50, etc. for the different periods. > > Using a combination of traits and SA any Security instance then has > some new attributes, sec.sma10 for instance. Which is either > retrieved from the SMAFields table via SA or computed from methods > on the SMAFields class if needed. > > Though the really useful bit is querying: > sess.query(Security).filter(Security.sma10 <= Security.sma20), > which behaves as one would expect. > > The idea being that the user can easily add new functions for > computing values from a security's data, and after the new table is > created and filled with the results, he can run normal sql queries > on it. Any other child classes that get added also have access to > the SMAFields class's fields through it's Security relation. Thus > a user can add as many child classes with as many columns as they > want, and have access to all the fields they've already set up. > I'm not sure something like that is possible through inheritance? > > The new fields can then be added to the table viewer in the gui and > basically be used as if they were part of the Security class from > the beginning, running sql queries being the most important > feature. > > It mostly works, though the really ugly hacking of SA I've done to > get it to work might not be perfect. > > Is there a more elegant way to this? Is this even the best > approach at allowing a user to add new behaviour to the > application? > > I'm new to SA and have never used any SQL before either so I'm sure > there must be better design patterns for something like this > already. > > I hope it's clear what my intent is now. > > Thanks again for you help svilen. > > Regards, > Christian > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
