Re: Django ORM query syntax enhancement

Hi Adam, I agree with some of your points. however djngo orm query syntax is the main pain point for anyone new to django orm. The reason those packages are not widely used is because most people dont know about them and not about this DEP. And most new users mainly end up learning built in q

Re: Django ORM query syntax enhancement

I would not be for merging anything into Django at this time. There are several libraries providing "enhanced" query syntax: django-orm-sugar, django-model-values, and django-natural-query. None of them seems to be particularly popular (<100 github stars, minimal PyPI downloads), and only django-m

Re: Django ORM query syntax enhancement

Hey all, can we have some consensus on this? Asif On Saturday, April 1, 2017 at 12:55:27 PM UTC+6 Alexey Zankevich wrote: > Hey all, > > Please check a draft DEP related to external query language support by > Django ORM https://github.com/django/deps/pull/40. > > Regards, > Alexey > > > On W

Re: Django ORM Internals

Hello, I would suggest https://www.youtube.com/watch?v=bgV39DlmZ2U if you'd like to understand how the ORM is structured in layers. -- Aymeric. Le lun. 13 mai 2019 à 12:16, Adam Johnson a écrit : > Yes there isn't much documented on the ORM internals, but there are other > resources. The DUTH

Re: Django ORM Internals

Yes there isn't much documented on the ORM internals, but there are other resources. The DUTH videos are a great start and inspired me to get started contributing to Django. Specifically: - https://www.youtube.com/watch?v=CGF-0csOjPw - https://www.youtube.com/watch?v=-4jhPRfCRSM - https:/

Re: Django ORM Internals

Great, thanks On Monday, May 13, 2019 at 1:17:08 PM UTC+4:30, J. Pic wrote: > > Hi Mahdi, > > I would suggest reading the code and test code in the tests/ directory for > the ORM. > > There might also be some videos from Django Under The Hood conferences, > found some here: > > https://www.googl

Re: Django ORM Internals

Hi Mahdi, I would suggest reading the code and test code in the tests/ directory for the ORM. There might also be some videos from Django Under The Hood conferences, found some here: https://www.google.com/search?q=Django+Under+The+Hood+orm&tbm=vid Best -- You received this message because yo

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

Thank you all for the replies. @Josh Smeaton Essentially yes; specifically I was wondering whether I was failing to consider behaviour that couldn't be modeled via a Q object, since as you mention the current https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relati

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

These queries are actually not equivalent. Consider the following code: >>> r = Related.objects.create(field='related') >>> r.main_set.create(field_one='1', field_two='3') >>> r.main_set.create(field_one='2', field_two='4') >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1')

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It sounds like you understand what the current behaviour is, and you think that it would be better modelled with Q objects, is that the case? I can see where you're coming from, as even the docs explain the difference loosely in terms of AND and OR. Q(entry__headline__contains='Lennon') & Q(ent

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

On 03/30/2018 08:57 AM, Ryan Hiebert wrote: It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ It's also addressed in the

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley wrote: > I have recently

Re: Django ORM query syntax enhancement

Hey all, Please check a draft DEP related to external query language support by Django ORM https://github.com/django/deps/pull/40. Regards, Alexey On Wednesday, March 22, 2017 at 10:07:51 AM UTC+3, Asif Saifuddin wrote: > > Hi Aric, > > I checked your package. it's nice too. thanks for the wo

Re: Django ORM query syntax enhancement

Hi Aric, I checked your package. it's nice too. thanks for the work. Asif On Monday, October 17, 2016 at 4:38:26 AM UTC+6, Aric Coady wrote: > > +1. I implemented much the same thing for part of django-model-values > , but went with F > expre

Re: Django ORM query syntax enhancement

+1. I implemented much the same thing for part of django-model-values , but went with F expressions as the basis instead. Primarily because F expressions already support operator

Re: Django ORM query syntax enhancement

Agreed about concatenation functions calls. It would be easy to achieve once filter will accept object-based lookups (previously we discussed expression objects). I think it would be even better to accept objects of expression builder instead (versus expressions directly) - it will separate builder

Re: Django ORM query syntax enhancement

+1 from me, too. I still think we should be able to get into a point where you can run queries like: Q.user.firstname.collate('fi').lower() == 'anssi' So, not only can you call regular transforms (like lower), but also transforms that take arguments. Other use cases are for example substrin

Re: Django ORM query syntax enhancement

+1 from me. I really like this approach to help making my queries more DRY. I also like how lightweight the library is altogether. Well done! For those looking for a direct link, here you go: https://github.com/Nepherhotep/django-orm-sugar On Thursday, October 6, 2016 at 1:04:56 PM UTC-4, Al

Re: Django ORM query syntax enhancement

Hey all, Just want to announce recent changes in Django ORM Sugar library, which might be useful in future Django query syntax enhancement (if ever happens). 1. Now it supports indexes and slices: >>> Q.data.owner.other_pets[0].name='Fishy' Q(data__owner__other_pets__0__name='Fishy') >>> Q.tags[

Re: Django ORM query syntax enhancement

Hey Anssi, Just pushed test_lookup_exclude and test_lookup_exclude2, which passed successfully. Can you please review if they cover exactly described case? Thanks, Alexey On Monday, October 19, 2015 at 2:28:42 PM UTC+3, Anssi Kääriäinen wrote: > > I did similar work in https://github.com/djang

Re: Django ORM query syntax enhancement

I did similar work in https://github.com/django/django/pull/4801. I aimed for 1.9, but had to defer the work due to problems with .exclude() filtering. The problem is that if you query with .exclude(LessThan(F('friends__age'), 30)), you'll get different results than with .exclude(friends__age__lt=

Re: Django ORM query syntax enhancement

Here is a link https://github.com/django/django/pull/5443, sorry :) Making F object as expression wasn't required, but I still had to create FieldExpression wrapper, which wrapped F object. Eventually, I thought it would confuse people, especially taking in account F objects referenced in doc a

Re: Django ORM query syntax enhancement

this is the PR josh https://github.com/django/django/pull/5443 On Monday, October 19, 2015 at 5:09:14 PM UTC+6, Josh Smeaton wrote: > > I think you forgot the PR link Alexey. I'd like to have a look at the > changes you've made. I'm not sure about the extensions to F() just yet, I'm > hoping th

Re: Django ORM query syntax enhancement

I think you forgot the PR link Alexey. I'd like to have a look at the changes you've made. I'm not sure about the extensions to F() just yet, I'm hoping they aren't actually needed for your patch to work, but will need to review to be sure. Cheers On Monday, 19 October 2015 21:49:37 UTC+11, Al

Re: Django ORM query syntax enhancement

Hi all, Here is a raw pull request, allowing lookup instances passing to filter method There are two new test cases working: 1. Passing lookup with F object: Article.objects.filter(GreaterThan(F('id'), Value(5))) 2. And passing lookup with transforms: Article.objects.filter(Contains(Upper(Low

Re: Django ORM query syntax enhancement

Lets concentrate on making expressions in filter calls and lookups as expressions reality. When we have done that we can try out different syntax approaches in 3rd party apps. Finally, after we have field tested the approaches, we can merge something in to Django. - Anssi On Thu, Oct 1, 2015 at

Re: Django ORM query syntax enhancement

> I think the `F('name').decode('utf-8')` syntax is a good candidate for core. When Django supports expression lookups, it will be possible to build syntax sugar third-party library on top of it. For example, it will be possible to implement dotted syntax for F objects: UserModel.objects.filter

Re: Django ORM query syntax enhancement

> On Oct 1, 2015, at 13:38, Anssi Kääriäinen wrote: > > +1 to not requiring all transforms to handle __underscore__ syntax. +1 > I think what we want to do is allow users choose which syntax they > prefer. The idea is that Django will support both JSONExtract('data', > path=['owner', 'other_pet

Re: Django ORM query syntax enhancement

+1 to not requiring all transforms to handle __underscore__ syntax. I think what we want to do is allow users choose which syntax they prefer. The idea is that Django will support both JSONExtract('data', path=['owner', 'other_pets', 0, 'name']) and data__owner__other_pets__0__name out of the box.

Re: Django ORM query syntax enhancement

No, not all Lookups or Transforms are required to handle __underscore__ syntax. The entire point of supporting object based lookups is to handle cases that get more complex than a single argument transform or a left and right hand side lookup. In particular, I think your Decode(utf8) example is

Re: Django ORM query syntax enhancement

Hi Mark, I can explain why long string is a bad design (other than anything I described earlier). In fact it assumes that the additional parameters can be serialized into alphanumeric string, which apply additional and unnecessary limitation. In my example above, it's not clear how to pass "ut

Re: Django ORM query syntax enhancement

I don't think complex cases need to have __ equivalents, but I also dispute that long chains like that are necessarily a bad API, I don't find your option 1 particularly neat compared to option 2. Worth noting though that you've used a 2-valued function there which is not a lookup in the same sense

Re: Django ORM query syntax enhancement

I'll try to turn lookups into expression (will use master branch). I also have a question. Meanwhile the old query syntax with underscores is pretty good for simple queries (like Model.objects.filter(name='Bob'), it gets really ugly for parametrized calls, a new JSONField is a good example of th

Re: Django ORM query syntax enhancement

I don't think we need split-to-subq support for Lookups before we make them expressions. Lookups as expressions are usable outside .filter(), and we need the split-to-subq support only in .filter(expression). - Anssi On Wed, Sep 30, 2015 at 8:46 AM, Josh Smeaton wrote: > I'm mixing my versions,

Re: Django ORM query syntax enhancement

I'm mixing my versions, sorry to those following along. 1.9 has just reached alpha. Lookups as Expressions should be doable for 1.10 which master is currently tracking. Cheers On Wednesday, 30 September 2015 15:31:24 UTC+10, Josh Smeaton wrote: > > The alpha for 1.10 has already been cut, and I

Re: Django ORM query syntax enhancement

The alpha for 1.10 has already been cut, and I'm not sure that the kinds of changes needed here are appropriate to add now that the alpha is out. One could *maybe* make the argument that changing Lookup to an Expression now rather than later is the right move considering Transforms just underwen

Re: Django ORM query syntax enhancement

On the core ORM side we need to make .exclude(LessThan(F('friends__age'), 30)) do a subquery. This way .exclude(friends__age__lt=30) does the same thing as the expression version. This isn't that easy to do. If we just use resolve_expression, then the friends relation will generate a join, and the

Re: Django ORM query syntax enhancement

1. Lookups should become Expressions, just as Transforms have become Expressions. This will let us process Lookup arguments as Expressions all the way the way through. I think this should be a major goal for version 1.11. 2. Chaining transforms is now possible since they are just Func expressi

Re: Django ORM query syntax enhancement

Here is a list of issues to solve to support explicit transforms and lookups by filter (and exclude) methods. 1. Make Lookup.__init__ signature to support initialization with F objects or string path (e.g. GreaterThan(F('user__id'), 10) or GreaterThan('user__id', 10)), not sure it's possible to

Re: Django ORM query syntax enhancement

Hi Josh, As https://github.com/django/django/pull/5090 pull request merged into master, I wanted to extend django-orm-sugar library with some functionality, related to passing transforms or lookup objects. Currently it's not clear to me how lookups or transforms can be used in that way. I'm tal

Re: Django ORM query syntax enhancement

The patch allowing F objects for select_related and prefetch_related methods was trivial, unfortunately F uses "name" field as a part of Expression interface, so dotted querying will conflict with internal field (as "name" is quite a popular name for model field). >>> Contains(F.user.name, "Bob

Re: Django ORM query syntax enhancement

Gotcha. So, F objects seem to be pretty good as generic interface to specify query paths, the only remaining patch - adding select_related and prefetch_related support. I'll preapare a preliminary pull request soon. On Tuesday, August 25, 2015 at 2:48:10 AM UTC+3, Josh Smeaton wrote: > > Expres

Re: Django ORM query syntax enhancement

Expressions have built in support for ordering with asc or desc, see here: https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.Expression.asc Meaning that -F() is never ambiguous, which is the main reason we went for the F().desc() API rather than using the minus sign

Re: Django ORM query syntax enhancement

Hey Josh, Here is the current state of F support by different functions: * annotations (Count, Sum etc) - work * order_by - works partially (only asc order supported) * select_related, prefetch_related - don't work So, F is not a universal interface for getting paths right now. Also, there is a

Re: Django ORM query syntax enhancement

Most expressions already support strings, and most that support strings expect them to be field_paths that can be wrapped in F() expressions. So you have two options really, without built in support from other expressions. 1. P.field.other.some_field() returns an F() 2. P.field.other.some_field

Re: Django ORM query syntax enhancement

What about the idea to add interface to specify paths with special class or callable? On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote: > > If I finish the patch in time (I think I have about a month left), then > it'll be included in 1.9. Review and comments on the PR wil

Re: Django ORM query syntax enhancement

If I finish the patch in time (I think I have about a month left), then it'll be included in 1.9. Review and comments on the PR will go a long way to helping me tidy it up sooner rather than later, so please feel free to review. Regards, On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey Zan

Re: Django ORM query syntax enhancement

Once Josh completes this patch https://github.com/django/django/pull/5090 (.filter method accepting class-based lookups and transforms), it will be almost everything required by third-party apps. Is it going to be a part of Django 1.9, by the way? Additionally, for pure flexibility, next method an

Re: Django ORM query syntax enhancement

+1 for making it doable for 3rd party apps. Regards, Michael Manfre On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen wrote: > I'm still thinking we shouldn't integrate any new query syntax into > 1.9. Instead lets make it easy to create 3rd party apps that offer > different querying syntax, a

Re: Django ORM query syntax enhancement

I strongly agree with the third party approach. On 18 Aug 2015 17:49, "Anssi Kääriäinen" wrote: > I'm still thinking we shouldn't integrate any new query syntax into > 1.9. Instead lets make it easy to create 3rd party apps that offer > different querying syntax, and then lets see which solution

Re: Django ORM query syntax enhancement

I'm still thinking we shouldn't integrate any new query syntax into 1.9. Instead lets make it easy to create 3rd party apps that offer different querying syntax, and then lets see which solution (if any) gets popular enough to be integrated into Django. - Anssi On Tue, Aug 18, 2015 at 5:54 PM,

Re: Django ORM query syntax enhancement

Just a quick thought: I could imagine some newbies could get confused by the python-like syntax and try to do: Equal(P.user.get_full_name(), 'Bob Someone') I don't think it's not a huge deal, but worth noting. On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote: > > Hi all,

Re: Django ORM query syntax enhancement

Hi all, Thanks for detailed response. I thought over the described expressions/ transforms patches and here are my thoughts about the best way to implement simplified lookups. Firstly, I want to describe which properties of the new syntax seem to be important: 1. Using Python operators to do bas

Re: Django ORM query syntax enhancement

I like this idea, too. The work I and Loic have been doing has been about transforms that can accept arguments. I don't see why the two styles couldn't be mixed directly. .filter(Q.user.profile.last_login.date(timezone='Europe/Helsinki') < '2015-01-01') .filter(Q.user.last_name.collate('fi').unac

Re: Django ORM query syntax enhancement

Hi Alexey, I find this approach really interesting, and I don't mind the API you've created at all. Even if this doesn't make it into Django, I think there's enough utility in your library that other people would want to use it. I'm not going to comment on specifics just yet like method names,

Re: Django ORM support for NoSql databases

On Thu, Dec 19, 2013 at 1:47 AM, Javier Guerra Giraldez wrote: > On Wed, Dec 18, 2013 at 12:18 PM, > wrote: > > > > Wouldn't an easy (i.e. straightforward) solution be to add an Django > "ODM" > > that mirrors the ORM wherever it makes sense? This sounds pretty close > to > > your second soluti

Re: Django ORM support for NoSql databases

On Thu, Dec 19, 2013 at 1:18 AM, wrote: > > > On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote: >> >> >> My claim is that complete abstraction of the data store shouldn't be the >> goal. What we should be aiming for is sufficient API compatibility to allow >> for two thing

Re: Django ORM support for NoSql databases

On Wed, Dec 18, 2013 at 12:18 PM, wrote: > > Wouldn't an easy (i.e. straightforward) solution be to add an Django "ODM" > that mirrors the ORM wherever it makes sense? This sounds pretty close to > your second solution, except choosing SQL vs NoSQL means users make a more > explicit choice wheth

Re: Django ORM support for NoSql databases

On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote: > > > My claim is that complete abstraction of the data store shouldn't be the > goal. What we should be aiming for is sufficient API compatibility to allow > for two things: > > * ModelForms wrapping a model from a NoS

Re: Django ORM support for NoSql databases

On Wed, Dec 18, 2013 at 4:41 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 17 déc. 2013, at 20:38, Karen Tracey wrote: > > https://groups.google.com/d/msg/django-developers/0IuJssTt8tc/TxdXQ2D0thcJ > > > Interesting. Now I remember reading that message last year. I have t

Re: Django ORM support for NoSql databases

On 17 déc. 2013, at 19:53, Javier Guerra Giraldez wrote: > On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin > wrote: >> Django’s ORM is entirely designed to translate between an object oriented >> API and SQL. That’s what its name says. It achieves this through roughly >> five layers that br

Re: Django ORM support for NoSql databases

On 17 déc. 2013, at 20:38, Karen Tracey wrote: > https://groups.google.com/d/msg/django-developers/0IuJssTt8tc/TxdXQ2D0thcJ Interesting. Now I remember reading that message last year. I have three reactions. First, Russell and I agree that the interest has faded. Currently, the best option is

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin wrote: > Django’s ORM is entirely designed to translate between an object oriented API > and SQL. That’s what its name says. It achieves this through roughly five > layers that bride the abstraction gap. > > Django’s ORM is fundamentally tied to

Re: Django ORM support for NoSql databases

On Tuesday, December 17, 2013 12:16:04 PM UTC-5, Aymeric Augustin wrote: > > Django’s ORM is entirely designed to translate between an object oriented > API and SQL. That’s what its name says. It achieves this through roughly > five layers that bride the abstraction gap. > > Django’s ORM is fund

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 2:05 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 17 déc. 2013, at 19:53, Javier Guerra Giraldez > wrote: > > > On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin > > wrote: > >> Django’s ORM is entirely designed to translate between an object >

Re: Django ORM support for NoSql databases

Hello I think there is a difference between an ORM and an Document-Object Mapper as MongoEngine, I don't know if django ORM is designed to play a role adapted to a Document-Object Mapper, if not you can always use apps to that could be integrated to the django world and also a document mapper ht

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 4:50 PM, Chris Wilson wrote: > Hi all, > > > On Tue, 17 Dec 2013, Tom Evans wrote: > >> On Tue, Dec 17, 2013 at 3:35 PM, parisrocks >> wrote: >>> >>> Waiting for official Django ORM support for NoSql databases. >> >> >> MongoDB (and the vast majority of NoSQL databases) ar

Re: Django ORM support for NoSql databases

Hi Chris, On 17 déc. 2013, at 17:50, Chris Wilson wrote: > There is no particular reason NOT to do it, unless one wants Django's ORM > layer to remain fundamentally tied to SQL. I don’t understand your sentence. To me it’s as if you were saying “there is no particular reason NOT to relay emai

Re: Django ORM support for NoSql databases

Hi all, On Tue, 17 Dec 2013, Tom Evans wrote: On Tue, Dec 17, 2013 at 3:35 PM, parisrocks wrote: Waiting for official Django ORM support for NoSql databases. MongoDB (and the vast majority of NoSQL databases) are not relational databases, they are document oriented databases, they store do

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 3:35 PM, parisrocks wrote: > Hi Django Users, > I tried Django recently and really liked the simplistic approach for > building sites. > But there's no official support for NoSQL databases like Cassandra or > MongoDB, there's a great community of NoSQL users waiting for an

Re: Django ORM enchantments

Very nice work Akaariai. I'll check this out over the next couple of days :) Cal On Mon, Jul 4, 2011 at 10:10 PM, akaariai wrote: > I have implemented proof of concept versions of conditional > aggregation, F-lookups in aggregates and annotating fields to a model > (qs.field_annotate(age_x2=F('

Re: Django ORM performance patch. Fixes #5420, #5768

Per my patches and what I believe Malcom has done with qsrf, the syntax for related fields was field__related__name, and yes, you would repeat this over and over, but it keeps it consistant. I would like a values-like method to return partial objects, and then requesting any field thats not "fill

Re: Django ORM performance patch. Fixes #5420, #5768

On 15 Feb, 12:30, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > When Adrian > proposed that API, he realised that almost always you're going to be > pulling back all of the fields or almost all of them. Once a database > has read a row to access some of the data, accessing all of the data in >

Re: Django ORM performance patch. Fixes #5420, #5768

On Fri, 15 Feb 2008 21:30:23 +1100 Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > There's also the fairly pragmatic side-effect that if you are only > pulling back a very few fields, there isn't really a lot your model > methods are going to be able to do without loading more data, unless > they

Re: Django ORM performance patch. Fixes #5420, #5768

On Fri, 15 Feb 2008 01:54:24 -0800 (PST) Dima Dogadaylo <[EMAIL PROTECTED]> wrote: > > Of course, this decreases database load, but IMHO it is better to > > use QuerySet.values if you want select just certain values from a > > model. > > Often I need methods defined in models and isn't available

Re: Django ORM performance patch. Fixes #5420, #5768

On Fri, 2008-02-15 at 01:54 -0800, Dima Dogadaylo wrote: > On 14 Feb, 17:26, Sebastian Noack <[EMAIL PROTECTED]> > wrote: > > > > Of course, this decreases database load, but IMHO it is better to use > > QuerySet.values if you want select just certain values from a model. > > Often I need method

Re: Django ORM performance patch. Fixes #5420, #5768

On 14 Feb, 17:26, Sebastian Noack <[EMAIL PROTECTED]> wrote: > > Of course, this decreases database load, but IMHO it is better to use > QuerySet.values if you want select just certain values from a model. Often I need methods defined in models and isn't available at dictionaries. For example get

Re: Django ORM performance patch. Fixes #5420, #5768

> I made a patch for Django to add QuerySet.fields(*fields, > **related_fields) and make possible to load only some from master and > related models fields. It allows to tune various object list queries > when we need only limited subset of all fields, improve general > performance and decrease da

Re: Django ORM performance patch. Fixes #5420, #5768

On Thu, 2008-02-14 at 03:50 -0800, Entropy Hacker wrote: > I made a patch for Django to add QuerySet.fields(*fields, > **related_fields) and make possible to load only some from master and > related models fields. It allows to tune various object list queries > when we need only limited subset of

Re: django ORM

On 11/22/07, Goutham DL <[EMAIL PROTECTED]> wrote: > Iam new to this community. I would like to know more about the django > ORM(i.e its internal workings). Can someone provide some good links > for this? http://code.djangoproject.com/wiki/DevModelCreation -- "Bureaucrat Conrad, you are technic

Re: django ORM

I have downloaded the source code and gone through the official documentation :).Iam more interested in how django does the mapping from the code to SQL. Goutham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Dja

Re: django ORM

On Nov 23, 8:18 am, Goutham DL <[EMAIL PROTECTED]> wrote: > Hi, > Iam new to this community. I would like to know more about the django > ORM(i.e its internal workings). Can someone provide some good links > for this? Hi Goutham, If you're new to the community, ensure you have a good understandi

Re: Django ORM bug when your app has a model named "ContentType"?

> Could this be related to #2874 ? 2874 looks related in that it is another bug resulting from a similar type of circular table relationship. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" grou

Re: Django ORM bug when your app has a model named "ContentType"?

On 2/28/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > [...] > > But! I did find the root of what's causing this bug and it may occur > regardless of the name of the model... > > Our content system has these relationships: > > Content -> ContentType > Content -> Attribute -> ContentType >

Re: Django ORM bug when your app has a model named "ContentType"?

On Feb 9, 3:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > So after some back and forth about whether this should or shouldn't > work, there didn't seem to be any resolution. Your gut feeling looks > right to me Rob: it should probably work as you expect (no collision), > although it won't

Re: Django ORM bug when your app has a model named "ContentType"?

On Wed, 2007-01-31 at 17:41 -0800, Rob Hudson wrote: > > Keep in mind that django.contrib.contenttypes gets installed by > > default, and is used by the comments app, the auth app, the admin app > > and the generic relations framework. > > > > It's hard to escape it :) > > I quickly grepped the

Re: Django ORM

Hi all. I agree with Benjamin completely. I hate Identity Map and synchronization approach. They break database logic like trigger or view. 2007/2/5, Benjamin Slavin <[EMAIL PROTECTED]>: > > I've also given this some consideration -- I haven't found any > information on this either. > > It would

Re: Django ORM

I've also given this some consideration -- I haven't found any information on this either. It would be nice if the DB API could make use of the cache system (memcached) if you attempt the lookup by ID. Synchronization becomes more of a problem... and it certainly removes transactional safety fro

Re: Django ORM bug when your app has a model named "ContentType"?

Rob Hudson wrote: > But it's just a model name... Django doesn't break if you have an app > with a model name of "Car", and another app with a model name of "Car". > It's pretty good at keeping the models separated by app. I took at look > at django.db.models.loading from the shell and it's keep

Re: Django ORM bug when your app has a model named "ContentType"?

> Keep in mind that django.contrib.contenttypes gets installed by > default, and is used by the comments app, the auth app, the admin app > and the generic relations framework. > > It's hard to escape it :) I quickly grepped the docs directory and it's not mentioned that you can't have a model n

Re: Django ORM bug when your app has a model named "ContentType"?

On 1/31/07, Brian Beck <[EMAIL PROTECTED]> wrote: > I agree; if your app isn't using the bundled ContentType, why should Django > complain if you make your own? Keep in mind that django.contrib.contenttypes gets installed by default, and is used by the comments app, the auth app, the admin app an

Re: Django ORM bug when your app has a model named "ContentType"?

Rob Hudson wrote: >> Django has a builtin type called "ContentType", >> http://code.djangoproject.com/browser/django/trunk/django/contrib/con... >> >> I'd just rename yours to something else and be done with it. > > As a workaround, sure. I've already worked around the issue. > > But I don't t

Re: Django ORM bug when your app has a model named "ContentType"?

On 1/31/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > > Django has a builtin type called "ContentType", > > http://code.djangoproject.com/browser/django/trunk/django/contrib/con... > > > > I'd just rename yours to something else and be done with it. > > As a workaround, sure. I've already worked

Re: Django ORM bug when your app has a model named "ContentType"?

I don't see that as a limitation, think of it as a reserved word! you can use MyContentType. Or maybe a core-dev can think more on this and provide a better solution to allow gaving duplicate names (but I'm not sure if this problem applies to models on different apps or just on "some" models that

Re: Django ORM bug when your app has a model named "ContentType"?

> Django has a builtin type called "ContentType", > http://code.djangoproject.com/browser/django/trunk/django/contrib/con... > > I'd just rename yours to something else and be done with it. As a workaround, sure. I've already worked around the issue. But I don't think Django would want this typ

Re: Django ORM bug when your app has a model named "ContentType"?

On 1/30/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > I'm getting a weird bug here and this is what I've deduced... > > I've got a "Page" model and a "Content" model. Content has a FK to > Page. I also have a "ContentType" model and Content has a FK to > ContentType. This is where I tell it if