> Excellent! I think you're right about SQLAlchemy needing a > declarative way of defining objects.
Cool, I think I am right too, ironically enough ;) > Couple of suggestions: > > 'onetomany' and 'onetoone' would be more readable as 'one_to_many' > and 'one_to_one'. Or because, they're classes, 'OneToMany' and > 'OneToOne' in accordance with PEP8 standards. Done, I changed it to one_to_one and one_to_many. Mike Bayer had originally suggested the names, as lowercase names tend to look more like a DSL, which is kind of what we want. However, I agree with you that the underscores make it easier to read. > __table__ could default to a lowercase version of the classname if > it's not specified in the mapping class. That would be a useful > convention which could be overridden in those few cases where the > table name couldn't be derived like that. Great idea. Done. > BTW, there's some interesting examples of meta programming for this > kind of thing here: http://blog.ianbicking.org/more-on-python- > metaprogramming.html I have read this before, and I really liked what I saw. However, I am not really out to clone the DSL that Rails' ActiveRecord is using, or clone SQLObject. I am trying to make something that fits in well with the SQLAlchemy style. Its interesting that Ian says that implementing something like this would be hard: class Person(ActiveRecord): belongs_to('project_manager') has_many('milestones') has_and_belongs_to_many('categories') This is very similar to what I have implemented, actually. Its not very difficult with metaclasses, I don't think. Of course, this has a lot to do with how exceptionally well Mike Bayer has designed SQLAlchemy, and the fact that my implementation ignores some of the more complicated things. Plus, I think explicit relationship management is more pythonic anyway. I think that: class Person(ActiveMapper): milestones = one_to_many('Milestone', colname='person_id') is much more clear than the magical ActiveRecord way to do things. > Something you didn't mention - is it necessary to call > 'process_relationships()' and 'create_tables()' once you have all > your classes defined? It is _currently_ necessary because of my implementation. The problem is that process_relationships needs to have access to all related classes in order to do its job, so right now I do the easy thing and wait until all classes are defined before calling it manually. However, I have a plan to make this automatic. I will put a call to process_relationships into the metaclass, so I can do the work progressively. But, I will check to make sure that all needed classes have been defined at the beginning of process_relationships, and if they haven't, defer the processing of relationships to the next call, etc. If someone wants to take a crack at this, please feel free. It shouldn't be all that hard. As for create_tables, this is a similar, but I think more complicated problem. At some point, there will need to be logic for creating tables, foreign keys constraints, etc. that is smart enough to manage dependencies. I have no idea how to solve this problem, and would love some help. Thanks for the feedback! -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
