Norjee, You touched on a point I've been trying to figure out for a bit. Using SA is inevitably going to lead to having people maintaining two sets of models. This was a bit of a concern for me.
My goal here is to make the SA models as minimal as possible. The end idea will be to let people specify SA models just to override what would be automatically created by my app. Ie, my code did something wrong. So they just specify it by hand and all is good (and they submit a bug, and I fix it, and then they're back to no extra SA code). Granted I think there might end up being bits that I won't be able to introspect from the DB and/or the django models. (legacy databases with some funky setup). As to returning data as a list of dicts or some such, this isn't a feature that I'm going to worry about. I can't say that I've done any testing on this, but if you're worried about the overhead of creating objects for each row, then maybe you should look into using the raw DB-API to get your data. Paul Davis On 10/6/07, Norjee <[EMAIL PROTECTED]> wrote: > > Hi from the Jeroen guy ;) > > As you can see my version of mixing sqlalchemy and django is a bit > dormant. At the very least it needs some changes to work with > sqlalchemy .4. Besides my code is a bit sloppy, as much of the > translation django syntax -> sqlalchemy syntax was trial and error. > > What my solution basically does is translate the django mapping to > sqlalchemy mapping, give the django model an inner class which will > then be the sqlalchemy model. > http://jeroen.concept-q.com/projects/djangoalchemy/readme.txt > explains it nicely. > > For now this isn't too exiting, however, it means you have only one > set of model to maintain, all the relations and custom names of fields > will be the same in the sqlalchemy model. Moreover, it should be > possible to use custom methods from the django model in the sqlalchemy > model. It is my guess that with little effort it should be possible to > emit the signals django models send as well.. > > One thing that does not work yet are generic relations. Those seem > pretty django specific. > > One more advanced thing i would REALLY love to see is some form of > lazy object initialisation. Both the django and sqlalchemy ORM > immediately create an object, while often the basic dictionary of rows > would suffice (when you query for the last 10 posts, you really don't > need the post object, only the rows with post id, title, and time. > Only when you start manipulating a single post, you need the object to > call, for example, the save method. It seems to me that once an > unknown method is being called, it is a nice time to "upgrade" the > simple dictionary to a full blown object with save method..) However, > i'm a bit clueless how to implement this ;) > > Anyway, good luck with the django + sqlalchemy solution. "Steal" as > many ideas you want. The development of my thingy will probably go > slow, as the main reason for publishing such an alpha status solution > was to get others to think on getting sqlalchemy to work inside > django. (Sadly (or fortunately as it means the django ORM _is_ > sufficient for all) there seems not much interest in blending > sqlalchemy in django, so don't expect lots of (external) need for your > project) > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
