Re: Django ORM

[Russell Keith-Magee]

On Thu, Nov 22, 2012 at 7:34 AM, Alexandra Paredes <05-3...@usb.ve> wrote:

Good afternoon,

I'm an student of Computer Engineering from Simón Bolívar University, in Caracas Venezuela. I'm working with a friend on a thesis about ORM and their "respectfulness" on databases.For a better understanding of Django ORM,  we tried to read the code itself as subject by Russ Magee on an email, but know we're wondering what would it be the consequences of not working with Django ORM, What features of the framework may be affected.

The only things that will be affected are things that need to access the database. Anything else -- request handling, form handling, caching, sending mail, and so on -- will continue to work fine. I've even heard of people using Django's requests and views, but using SQLAlchemy or NoSQL libraries for data store access.

The side effect of this will be that you lose the benefits of the most of the ecosystem of Django apps -- for example, you won't even be able to use the contrib auth or admin apps unless you're using the ORM -- but that's just because they need to store and/or access data in a database. Django's ORM provides a common language for data access that 3rd party apps can rely on; if you're not going to use that common language, you're going to need to build a lot on your own.

So - the short version -- the ORM is only used to access and modify data in a database. As long as you're not doing that, you don't need to use the ORM. However, most websites will be accessing a data store at some time, in practice, this is a pretty big limitation.

Yours,

Russ Magee %-)

[I単igo Medina]

On Wed, 21 Nov 2012, Alexandra Paredes wrote:

> Good afternoon,
>

> I'm an student of Computer Engineering from Sim�n Bol�var University, in

> Caracas Venezuela. I'm working with a friend on a thesis about ORM and
> their "respectfulness" on databases.For a better understanding of Django
> ORM, we tried to read the code itself as subject by Russ Magee on an
> email, but know we're wondering what would it be the consequences of not
> working with Django ORM, What features of the framework may be affected.

Always you need some kind of database management (most common situation in
practice), the consequences would be _big_.

i�

>
>
> In advance, thank you very much.
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/CnhVJKWfVJ0J.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>

[Alexandra Paredes]

Hi Russ, 

Thanks for the response, well we're thinking in modifying Django ORM to add some requeriments we consider important on databases. And specially if you already have the DB already build and want to import it to build the model part of the app. We're studying the code and we wonder if we can ask questions or received some kind of support when working with the ORM itself,

Thanks again

[Russell Keith-Magee]

On Sun, Nov 25, 2012 at 10:51 PM, Alexandra Paredes <05-3...@usb.ve> wrote:

Hi Russ, 

Thanks for the response, well we're thinking in modifying Django ORM to add some requeriments we consider important on databases. And specially if you already have the DB already build and want to import it to build the model part of the app. We're studying the code and we wonder if we can ask questions or received some kind of support when working with the ORM itself,

Feel free to ask; however, keep in mind that Django is a volunteer project, and while we'll try to answer questions, there's no guarantee that you'll always be able get an answer (or get an answer in a timely fashion).

If you do want to ask questions about adding new features to the ORM or database backends (rather than just general 'how does it work' questions), you'll be better served asking on the django-developers mailing list -- that's a list focussed on the development of Django itself.

I'm also intrigued as to the features that you think are important and are missing. Some features are missing due to a lack of interest from the community (or, at least, a lack of volunteers willing to build the feature); however, there are also some features that have been specifically rejected at a design level. Before you embark on a massive project, it would be worthwhile to validate that your high-level goals will be looked upon favourably by the core team.

Yours,

Russ Magee %-)

[Alexandra Paredes]

Ok, well the things we're looking to add and/or improve are: Composed primary key (although we're worried of the difficulty of this one in particular . Other thing we notice is that Django emulate the DELETE ON CASCADE, making select and deletes instead of using the DB constraint and we would like to change this. And basically we would like to make this kind of changes, the idea our thesis is that web frameworks like Django give the possibilities to develop web apps easily, and databases (specially DBMS) are optimized for managing data. So our goal is to see the ORM of Django can take advantage of this features so queries can be even more efficient. 

Thank you very much,

Ale 

[Russell Keith-Magee]

On Tue, Nov 27, 2012 at 3:33 AM, Alexandra Paredes <05-3...@usb.ve> wrote:

Ok, well the things we're looking to add and/or improve are: Composed primary key (although we're worried of the difficulty of this one in particular .

A lot of work has already been done on this problem. See Ticket #343 [1], and the work that has been done on a branch stemming from the 2011 Google Summer of Code.

[1] https://code.djangoproject.com/ticket/373

[2] https://github.com/koniiiik/django/tree/soc2011/composite-fields

Other thing we notice is that Django emulate the DELETE ON CASCADE, making select and deletes instead of using the DB constraint and we would like to change this.

This shouldn't be too hard to implement. The biggest problem here is that not all databases support cascading deletes (or implement them correctly, in some cases). However, for those that do support it (which is to say PostgreSQL and Oracle), an implementation of native cascading delete should really be case of *not* calling code, rather than needing new code. Deletion strategies are already abstracted behind an interface (See [3]), so it should be fairly easy to drop in a simpler implementation.

[3] https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete

For the most part, this could be implemented by doing *less* - Django's deletion infrastructure is already genericised, and putting in an implementation that *doesn't* delete individual objects will really only involve *not* calling code.

 

And basically we would like to make this kind of changes, the idea our thesis is that web frameworks like Django give the possibilities to develop web apps easily, and databases (specially DBMS) are optimized for managing data. So our goal is to see the ORM of Django can take advantage of this features so queries can be even more efficient. 

Django is already used to develop web apps easily, and databases are clearly good for managing data. I'm not sure how a couple of select optimisations in the ORM advances this thesis. A better database layer won't make it any easier to develop web applications -- by definition, the ORM abstracts the implementation details, and a better database layer won't improve the data management capabilities of a database. 

Of course, this is something you need to take up with your own professor/tutor. I might be missing some important details that are specific to your course requirements.

Yours,

Russ Magee %-)