Hi Russell, Thank you for your response it has mainly answered my questions as well as given me areas to think about where to insert the asynchronous layer.
Edward On Tuesday, 11 November 2014 21:25:44 UTC, Russell Keith-Magee wrote: > > Hi Edward, > > On Tue, Nov 11, 2014 at 12:30 AM, Edward Armes <edward...@gmail.com > <javascript:>> 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/8d2f2ea6-10cc-4d43-adbb-0ce17515c36d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
