Quick update: I've got this working so that Django models are automatically introspected to create all the same backrefs for use in SA that you would have access to in Django.
SA Table's and Mapper's can be overridden in your app so you can add custom methods to your models. Due to popular demand, you can use your Django models as the ORM objects. I'm in the process of filling out some documentation on the wiki. If anyone has any comments or suggestions I'd like to hear them. All in all, adding SQLAlchemy to your Django project takes three lines of code. Paul Davis On 10/6/07, Ben Ford <[EMAIL PROTECTED]> wrote: > Hi Paul, > > Model field values are just the value of that field in the database, *not* > the field itself. The fields themselves are atored in _meta.fields and > _meta.many_to_many. The field does all of it's work by looking at the model, > i.e. getattr(model_instance, field_name). > > So it makes no difference if you change the value. Therefore when a model is > created, it should make no difference if the field value are set by django > or SA... as long as they are the same then there's no problem. > > This is a bit of a superficial explanation, as of course it makes no > allowance for the case where the db_column has been set in the field and is > therefore different to the attribute name applied to the model. However I > think the theory is sound. > > Ben > > > > On 07/10/2007, Paul Davis <[EMAIL PROTECTED]> wrote: > > > > Ben, > > > > If I understand you right, you're arguing to merge the SA and Django > > models so that we can use Django's reverse lookups. > > > > SA supports reverse lookups and I'm just getting started on > > implementing these automagically by introspecting the django models. > > > > I'm still not convinced that overriding Django model fields with SA > > model fields is a good idea. There seems to be quite a bit of code in > > the Django fields for dealing with forms and what not. I'm assuming > > that this is an artifact of oldfields and will be removed eventually, > > but until then all code depending on oldfields would choke. Something > > I'm trying to avoid. > > > > The only reasons that I can come up with supporting using Django > > models as a base would be to try and automatically use the extra > > methods defined for a model or *maybe* using the custom managers. > > > > Both of these 'features' seem like they would present an endless can > > of worms because of all the implicit relationships between the django > > models, fields, and managers. > > > > At the moment, I'm trying to keep things as straightforward as > > possible so its easy to switch back and forth between the two model > > styles. > > > > Anyway, thanks for your thoughts. Hopefully I can introspect all the > > relationships and have back references working automatically before I > > go home tonight. > > > > Paul > > > > On 10/5/07, Ben Ford <[EMAIL PROTECTED]> wrote: > > > Hi Paul, > > > > > > I don't think it would entail two db lookups, but like I said I haven't > > > tested it. SA will be instantiating a django Model, but it will be > filling > > > in it's data from the database, so there should be no lookup required by > > > django. > > > > > > It does overwrite the field as far as I know, but that shouldn't matter > in > > > because all you get from a field is that field's value from the database > > > anyway. The django ORM is still usable... So you still get the ability > to do > > > reverse related lookups and such, even from objects in a list returned > by > > > SA: i.e. if you have the following > > > > > > class Alarm(models.Model): > > > .... > > > ran_obj = models.ForeignKey(RANObject, related_name='alarms') > > > ..... > > > > > > and you get a list of RANObjects from some complicated lookup that you > use > > > SA for, then you should still be able to do: > > > > > > ran_ob.alarms.all() > > > > > > This is one case where I could envisage using SA and django ORM side by > > > side. > > > That way you won't have to mess with any of your views/admin/django core > > > functionality, as the underlying objects are still just django models. > > > > > > What do you think? > > > > > > Ben > > > > > > On 06/10/2007, Paul Davis < [EMAIL PROTECTED]> wrote: > > > > > > > > SmileyChris, > > > > > > > > At the moment, I'm using the class_prepared signal to gather all > > > > loaded models. Theoretically I could use this to attach an SA > > > > attribute. > > > > > > > > Are there use cases out there where you'd want to use *both* the > > > > Django and SA ORM's side by side? To me it makes more sense to import > > > > one or the other depending on what you plan on doing. For instance all > > > > of my code will use just the SA models, but the admin will still use > > > > the Django models. > > > > > > > > Paul > > > > > > > > On 10/5/07, SmileyChris < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > On Oct 6, 5:24 am, "Paul Davis" <[EMAIL PROTECTED] > > wrote: > > > > > > Ben, > > > > > > > > > > > > I contemplated something like this, but I assumed that field > > > > > > properties would clash. For instance, after the call to > mapper(...) > > > > > > you would no longer have access to Django ORM fields with the > > > > > > Model.field syntax (as they would be replaced by SA's). > > > > > > > > > > Could you use the post_init signal to attach a LazySAModel object as > > > > > an SA (or something) property of all newly created Django models? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > Ben Ford > > > [EMAIL PROTECTED] > > > +6281317958862 > > > > > > > > > > > > > > [EMAIL PROTECTED] > > +6281317958862 > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
