Decoupling the ORM

Having worked through the code of several Django nosql/alternative database backend libraries, forks, etc... I've noticed that that one of the biggest challenges they run into, is 'conforming' to many of the things Django expects these lowest layers to do. I opened this ticket https://code.dja

Re: Decoupling the ORM

On Tuesday, December 15, 2015 at 5:43:55 PM UTC+2, Samuel Bishop wrote: > > Having worked through the code of several Django nosql/alternative > database backend libraries, forks, etc... > > I've noticed that that one of the biggest challenges they run into, is > 'conforming' to many of the thin

Re: Decoupling the ORM

I'm definitely not going to be more helpful than Anssi, but feel free to take a look on Djangae , a Django database backend for non-relational datastore on Google App Engine. We've also got a chat and a mailing list if you wanna have a chat with us. Here ar

Re: Decoupling the ORM

After many years idly wanting the feature, and having looked at the existing "state of the art" when it came to Django and alternative Databases, it was Djangae that convinced me that this is doable and got me "over the ditch" to where I now stand, Djangae on one side of me as proof, a working

Re: Decoupling the ORM

By the time I opened the issue ticket I had become convinced that the DB Compiler was effectively an impossible route. I completely agree with your sentiments about implementing Compiler. I'd go as far as to suggest that few small documentation changes may be warranted in order to suitably expl

Re: Decoupling the ORM

I've identified one new "issue". There is an implicit assumption that primary keys are useful for ordering by the current QuerySet API methods `.first()` and `.last()`. I believe the case here is that first and last are meaningless without an ordering, so in lieu of any programmer supplied orde

Re: Decoupling the ORM

I agree that the current uuidfield is a simplistic solution to be used as autofield, and having a way to specify your autofield type globally would be good, equally something like a biginteger field. The complexity involved with doing this (custom RETURNING statements, database level defaults, inte

Re: Decoupling the ORM

You've raise a very good point, one that has been on my mind the entire time I've been exploring this. Much of Django has been designed 'on the back of' the ORM, reliant on its limitations and without need to go beyond the scope of what it can provide, its very probable that over time this has

Re: Decoupling the ORM

As far as I'm concerned, anything we can do to simplify and decouple abstraction layers is a good thing and would be welcomed, with the usual caveats of backwards compatibility in public and pseudo-public APIs. models.query is a thin layer over models.sql.query. That's a good thing. Ideally, mo

Re: Decoupling the ORM

I was more referring to 'above' in a broad way, as the fields are constructed from the data returned by the ORM when building the model. which should also be above the ORM. Pulling open the Django code in PyCharm and taking a look at things, with an eye towards "lots of smaller incremental imp

Re: Decoupling the ORM

When I wrote small I was thinking along the lines of clearing up particular methods to ensure they're not breaking semi-formal contracts. Layering on a new abstraction to fields is quite a bit bigger, but is still small relative to the goal of "decoupling the ORM". If you c