HI guys, Thanks for your responses, they have indeed answered all my questions pretty much as I was mainly looking for information on how to modify how Django accesses it's ORM layer. However from your answer it seems that it would be better that I do it at the model layer. I apologize for being so vague in my question it was semi-deliberate as I wanted to avoid people posting application specific solutions like "Use module X and do Y" and often when you ask questions reguarding internals on open-source projects and other places (i.e. Stack Overflow) you normaly get a load people responding with "why?" which for understandable reasons I wanted to avoid.
To follow on from this I have a few more quick questions:- - If my understanding is correct the Django admin interface uses the model layer? If so while learning Django I remember reading (although I can't find the link now) that if you use a model that doesn't use Django database layer the admin code doesn't work? if this is the case why so? - Secondly would I be correct in thinking that by having asynchronous models it would break the default forms and views lthat are included ike the wonderful Admin package? Many Thanks. Edward On Wed, Nov 12, 2014 at 6:09 AM, Kakar Nyori <nyorika...@gmail.com> wrote: > Very nicely explained. > > On Wed, Nov 12, 2014 at 2:55 AM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> Hi Edward, >> >> On Tue, Nov 11, 2014 at 12:30 AM, Edward Armes <edward.ar...@gmail.com> >> wrote: >> >>> Hi there, >>> >>> I am currently looking at Django for a personal project. While I >>> understand how a lot of it works I can't wrap my head around how the actual >>> DB querying is done specifically what part of Django actually looks at the >>> database (I'm not talking about Manager, Models or Querysets, but the >>> actual parts of Django that use the ORM's to get data from the database >>> itself). >>> >>> If a reason is required without going into detail on my current >>> half-baked idea, I'm specifically looking how to handle database operations >>> that have a significant return time by marrying asynchronous environments >>> with synchronous ones. While it may be more efficant to use a non-Django >>> database handler. For now I want to look into using the Django framework >>> without needing additional imports. >>> >>> >> It's not that a *reason* is required - it's that it's not entirely clear >> what you're asking for. >> >> The thing is, Django *itself* doesn't do a lot of querying - Django is a >> template system, and a forms layer, and a database ORM, all nicely >> integrated, so you can easily compose the pieces to do something useful. >> There are places where the forms layer will issue queries (e.g., if you >> want to display a form that has a <select> representing the available >> options from a model), but that's really at the level of "give me a >> queryset that represents the options I want to display". >> >> The only part of Django *itself* that "uses" Django is the contents of >> the contrib apps - most importantly, contrib.admin, but there are others. >> >> The idea of marrying async and synchronous environments isn't a new one - >> it was the subject of a Google Summer of Code project this year, the result >> of which will hopefully be committed to trunk for 1.8. The core of that >> project was to formalise the API around Django's model layer so that you >> can write a "duck typed" object that will be a substitute for a Django >> model (subject to certain constraints and limitations). Search the >> Django-Developer archive for "Meta Refactor" if you want more details. >> However, that won't let you get away "without needing additional imports" - >> at some point, you're going to need to import your async layer, because >> Django doesn't have one. >> >> I don't know if any of this helps... hopefully it does :-) >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users+unsubscr...@googlegroups.com. >> To post to this group, send email to django-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAJxq848_Oy_oWhLnu5h8dfgT1MW8CKny_ZQKZcQ4nCdO9_W%2B5g%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAJxq848_Oy_oWhLnu5h8dfgT1MW8CKny_ZQKZcQ4nCdO9_W%2B5g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/QT27WcWMlLM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CA%2B8oko%2BZquCXnCV5k9WRMevYRMX4Unca_EhimKTQdCCcuzqQAA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CA%2B8oko%2BZquCXnCV5k9WRMevYRMX4Unca_EhimKTQdCCcuzqQAA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAC4s8ZNm_%3DB1LsMpy9BWU7BjSQZwsHTUW_fe7C1ikZavLQ5u%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
