Re: proposal: add special subclass of ForeignKey for storing ContentTypes

ote: > Hi Sergey, > > I was also wondering why GenericForeignKey don't have direct subclass of > ForeignKey while writing a dep about field API improvement. Though I am not > 100% sure your implementation. > > Thanks for bringing it up. > > > > On Wednesday, Ap

Re: proposal: add special subclass of ForeignKey for storing ContentTypes

Hi Sergey, I was also wondering why GenericForeignKey don't have direct subclass of ForeignKey while writing a dep about field API improvement. Though I am not 100% sure your implementation. Thanks for bringing it up. On Wednesday, April 5, 2017 at 2:46:31 AM UTC+6, Sergey Fedoseev

proposal: add special subclass of ForeignKey for storing ContentTypes

Hi all, Some time ago I created 'new feature` ticket <https://code.djangoproject.com/ticket/27580> and Tim Graham asked me to write here to get some feedback on the idea. So here it is. ContentType model is quite specific, so we could add the subclass of ForeignKey with some specif

Re: Django 1.8 Migrations: AlterField Migration calls default callable for ForeignKey even when no Model Instances Exist

Hi, I think the issue is described in https://code.djangoproject.com/ticket/24182. On Tuesday, March 14, 2017 at 12:50:52 PM UTC-4, Dylan Young wrote: > > Steps to reproduce: > > Create Model > Make migrations > Add FK to model with a callable default that has some side effect (e.g. > creating t

Django 1.8 Migrations: AlterField Migration calls default callable for ForeignKey even when no Model Instances Exist

Steps to reproduce: Create Model Make migrations Add FK to model with a callable default that has some side effect (e.g. creating the default instance in the database) Make migrations Migrate (or run tests on clean db) Observe the side effect I couldn't find this on the Bug Tracker. Is this stil

Re: Implicit ForeignKey index and unique_together

tween unique_together and a ForeignKey, where unless an explicit `db_index=False` is set on the foreign key, Django creates a redundant index (under MySQL at least, haven't checked the others). However this appears fixed on master - I thought originally it might have been inadvertently fix

Re: Implicit ForeignKey index and unique_together

I think that the issue on Trac is actually something different, it talks about the need (or not) of an index, when defining a unique constraint. Most databases (if not all) will create an index automatically when a unique constraint is defined, and correct me if I'm wrong, but PostgreSQL (I don

Re: Implicit ForeignKey index and unique_together

Did you try to find anything related in Trac? Maybe https://code.djangoproject.com/ticket/24082? I use this query in Google: postgresql unique index site:code.djangoproject.com On Friday, September 16, 2016 at 9:51:13 AM UTC-4, Dilyan Palauzov wrote: > > Hello, > > according to the documentati

Implicit ForeignKey index and unique_together

Hello, according to the documentation models.ForeignKeys creates implicitly an index on the underlying database. Wouldn't it be reasonable to change the default behaviour to only create implicit index, if there is no index_together or unique_together starting with the name of the foreign key?

Re: What is the purpose of adding `nowrap` class to all ForeignKey fields in django admin objects list?

u're > looking for. > > On Monday, December 7, 2015 at 8:33:34 AM UTC-5, alTus wrote: >> >> Django adds `nowrap` class to your `td` if you specify list_display to >> show any ForeignKey. >> I can't see the purpose to do it. Any considerably long title

Re: What is the purpose of adding `nowrap` class to all ForeignKey fields in django admin objects list?

_display to > show any ForeignKey. > I can't see the purpose to do it. Any considerably long title breaks table > layout hard. > Do I miss smth or may be it would be better to just remove it? > -- You received this message because you are subscribed to the Google Groups "

What is the purpose of adding `nowrap` class to all ForeignKey fields in django admin objects list?

Django adds `nowrap` class to your `td` if you specify list_display to show any ForeignKey. I can't see the purpose to do it. Any considerably long title breaks table layout hard. Do I miss smth or may be it would be better to just remove it? -- You received this message because yo

Re: Django explicit `order_by` by ForeignKey field

Wow, that's cool, thanks! As I see it was quite a long running issue. понедельник, 28 апреля 2014 г., 23:39:53 UTC+4 пользователь charettes написал: > > After discussion this was escalated to a release blocker in order to make > sure we don't miss the opportunity of fixing it correctly. > > I at

Re: Django explicit `order_by` by ForeignKey field

After discussion this was escalated to a release blocker in order to make sure we don't miss the opportunity of fixing it correctly. I attached a patch to the ticket that makes sure that explicitly ordering by a relation source field (group_id in your case) produces the expected result. Simon

Django explicit `order_by` by ForeignKey field

I've already started this topic in django-users ( https://groups.google.com/forum/#!topic/django-users/k9K7VsPe6aA) and got an advice there to ask here. It's not a big issue and it can be solved quite easily as I can see from django sources. Also there're some workarounds to deal with it but I wr

Re: ForeignKey in Inline generates lots of queries

jango users, but didn't get a response. I'd like to help > to resolve this issue if at all possible. > > Previous post: > > I have the Django admin configured with a TabularInline, and the inline > model has a ForeignKey reference to a third model. Every row in the inline

ForeignKey in Inline generates lots of queries

I posted this to Django users, but didn't get a response. I'd like to help to resolve this issue if at all possible. Previous post: I have the Django admin configured with a TabularInline, and the inline model has a ForeignKey reference to a third model. Every row in the inline g

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

Yup, qs.prefetch_related('best_pizza__toppings__topping_type', use_select_related=True) looks good enough for many cases. We have a lot of cases in the code where this would save many queries. On Tuesday, November 27, 2012 2:57:16 PM UTC, Anssi Kääriäinen wrote: > > On 26 marras, 21:36, tolomea

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

t; >>> >> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type') >> >> It doesn't seem to take advantage ``select_related`` (assuming that >> ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead >> sends a se

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

. However, if you use it like this: > > >>> > Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type') > > It doesn't seem to take advantage ``select_related`` (assuming that > ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead >

Re: db_type method for ForeignKey is buggy?

Hi Michał, On Monday 28 January 2013, Michał Nowotka wrote: > > This is db_type method definition: > > def db_type(self, connection): > rel_field = self.rel.get_related_field() > if (isinstance(rel_field, AutoField) or > (not connection.features.related_fields

db_type method for ForeignKey is buggy?

Hello django developers! This is db_type method definition: def db_type(self, connection): rel_field = self.rel.get_related_field() if (isinstance(rel_field, AutoField) or (not connection.features.related_fields_match_type and isinstance(rel_fie

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

On 26 marras, 21:36, tolomea wrote: > The focus then is on how to let the developer specify what they want in the > same query and what they want in a different query. > Select_related currently adds same query stuff and prefetch_related > adds separate query stuff. So what if we added a way for a

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

> email]<http://user/SendEmail.jtp?type=node&node=4997386&i=1>. > > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > -- > If you reply to this email, your message will be added to th

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

On 20/11/12 12:08, tolomea wrote: >> it should do exactly what the developer asks. > > How do I, the developer, request that it use select_related for topping_type > part of the best_pizza__toppings__topping_type example given above? Sorry for the slow reply. At the moment, there is no way to sp

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

ied-to-utilize-select-related-for-ForeignKey-relations-tp4486127p4996605.html Sent from the django-developers mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send em

Re: Custom ForeignKey which does not require referential integrity?

On Tue, May 29, 2012 at 8:21 AM, diabeteman wrote: > I posted first on django-users and then I thought that it was a bit too low > level for such a question. Django-devs is _not_ a "Django support, level 2" list. :-) -- Javier -- You received this message because you are subscribed to the Go

Re: Custom ForeignKey which does not require referential integrity?

Sorry about that, I posted first on django-users and then I thought that it was a bit too low level for such a question. I hope I'll get some help :-) On Monday, May 28, 2012 2:00:47 AM UTC+2, Karen Tracey wrote: > > Please do not crosspost to both django-users and django-developers. Pick > t

Re: Custom ForeignKey which does not require referential integrity?

Please do not crosspost to both django-users and django-developers. Pick the right list and post there. This seems to be more appropriate for discussion on django-users than here. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To po

Custom ForeignKey which does not require referential integrity?

reign keys". > **Do you know how I can code a custom field that will emulate a real > Django ForeignKey without creating a hard constraint on the database? > **Maybe this already exists, but I didn't have any luck on Google. > **Thanks in advance for the help :-) > **NB: I

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

On 19/02/12 22:18, Yo-Yo Ma wrote: > It doesn't seem to take advantage ``select_related`` (assuming that > ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead > sends a separate query for ``Topping`` and ``ToppingType``, joining > them in Python. Is it f

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

queries problem, which of course is > great. However, if you use it like this: > > >>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type') > > It doesn't seem to take advantage ``select_related`` (assuming that > ``topping_type`` i

Could prefetch_related be modified to utilize select_related for ForeignKey relations?

use it like this: >>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type') It doesn't seem to take advantage ``select_related`` (assuming that ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead sends a separate query for ``Topping`` and

Re: Question on ForeignKey (on_delete=DO_NOTHING)

I have ran the test suit in debugging mode also, and what i observed is sqlflush worked perfectly. I am currently investigating into this, if found something, will update you same. Thanks, Rahul Priyadarshi On Feb 4, 10:54 pm, Carl Meyer wrote: > On Feb 4, 3:41 am, Rahul wrote: > > > When i set

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Feb 4, 3:41 am, Rahul wrote: > When i set this flag in DatabaseFeatures  then for full test suit also > both test cases of "contenttypes" app works fine. > > But i am not able to figure out why this test case was failing when we > were not sets supports_transaction flag. It may be worth invest

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Thanks carl for you reply. we were setting supports_transaction flag in settings but now i get to know from Russ Megee's post(http://groups.google.com/group/django- developers/browse_thread/thread/5c1c3cdfd1e4728e/) that this flag has been moved to DatabaseFeatures. When i set this flag in Databas

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Hi Rahul, On Feb 2, 4:03 am, Rahul wrote: > When i run the entire inbuilt test suit of django, first test case it > hits is of contenttypes app of contrib apps and first test > case(intest_lookup_cache)  works fine. But when it hits the 2nd test > case (test_shortcut_view) it first flushes out al

Re: Question on ForeignKey (on_delete=DO_NOTHING)

When i run the entire inbuilt test suit of django, first test case it hits is of contenttypes app of contrib apps and first test case(intest_lookup_cache) works fine. But when it hits the 2nd test case (test_shortcut_view) it first flushes out all tables and then tries to insert data in "AUTH_PERM

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Carl, you are right. I didn't mention the actual problem i was facing... Prior to 1.3 the way we implemented 'sqlflush' was to simply turn on 'cascade_delete' in DB2 and then return 'delete from TABLENAME' for every table passed in. Without the delete_cascade, this required the delete's to be sor

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Jan 24, 3:51 am, Rahul wrote: > Can you let me know how i can specify that this test case should not > be run, when i run the inbuilt unit test-cases. Currently i just run > them like this 'python runtests.py --setting=settings' You should not avoid running test_do_nothing. It is written such

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Mon, Jan 24, 2011 at 4:51 PM, Rahul wrote: > Can you let me know how i can specify that this test case should not > be run, when i run the inbuilt unit test-cases. Currently i just run > them like this 'python runtests.py --setting=settings' http://docs.djangoproject.com/en/dev/internals/contr

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Can you let me know how i can specify that this test case should not be run, when i run the inbuilt unit test-cases. Currently i just run them like this 'python runtests.py --setting=settings' thanks Mario -- You received this message because you are subscribed to the Google Groups "Django deve

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Mon, Jan 24, 2011 at 3:26 PM, Rahul wrote: > Hi, > >  I am working on upgrading DB2 Django adaptor for 1.3. I had a small > question on the above. As per the docs of 'DO_NOTHING', you mention > 'IF' your DB backend enforces referential integrity, this will cause > an IntegrityError. > http://do

Question on ForeignKey (on_delete=DO_NOTHING)

Hi, I am working on upgrading DB2 Django adaptor for 1.3. I had a small question on the above. As per the docs of 'DO_NOTHING', you mention 'IF' your DB backend enforces referential integrity, this will cause an IntegrityError. http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.mo

Re: ForeignKey with null=True

On Dec 16, 2010 7:20 PM, "Christophe Pettus" wrote: > > > On Dec 16, 2010, at 2:31 PM, Luke Plant wrote: > > That being so, there is a case for arguing that > > ForeignRelatedObjectsDescriptor should not retrieve objects where the > > field pointed to is NULL - for consistency with the inverse ope

Re: ForeignKey with null=True

On Dec 17, 9:21 am, Carl Meyer wrote: > Instance._state.adding is new in 1.2 (in 1.2 it was instance._adding > and only ever monkeypatched onto a model instance by ModelForm; I > changed it to instance._state.adding and encapsulated it inside the > ORM just a few weeks ago in r14612). Oh - and

Re: ForeignKey with null=True

Hi Luke, On Dec 16, 9:47 am, Luke Plant wrote: > For the latter, I think we should use instance._state.adding to reliably > detect whether a PK has been set or not. This could cause some [snip] > While I was there,  I fixed _get_next_or_previous_by_FIELD to use > self._state.adding, rather than

Re: ForeignKey with null=True

On Dec 16, 2010, at 2:31 PM, Luke Plant wrote: > That being so, there is a case for arguing that > ForeignRelatedObjectsDescriptor should not retrieve objects where the > field pointed to is NULL - for consistency with the inverse operation. I agree with this. If the FK field is NULL, it should

Re: ForeignKey with null=True

On Thu, 2010-12-16 at 11:30 -0800, Christophe Pettus wrote: > On Dec 16, 2010, at 11:14 AM, Luke Plant wrote: > > This isn't true if the field pointed to (i.e. primary key by default) > > allows NULL values - in that case a ForeignKey field with a NULL value > > can and

Re: ForeignKey with null=True

I'm in favor of the patch you've provided, Luke. Raising an exception seems like the best option here to me. While it *is* a logical error to get the related objects of an unsaved instance, the current behavior seems buggy and (as Ian Clelland points out) it can be potentially harmful. FWIW, I

Re: ForeignKey with null=True

very straight way - change ForeignKey >> behavior (the piece of code that generates many_set method) - so it >> doesn't take into account null. >> >> Let me explain a bit more. If foreign key is null - then there's no >> link between Many and One object. So

Re: ForeignKey with null=True

On Dec 16, 2010, at 11:14 AM, Luke Plant wrote: > This isn't true if the field pointed to (i.e. primary key by default) > allows NULL values - in that case a ForeignKey field with a NULL value > can and should return a non-empty set of values when the related objects > lookup

Re: ForeignKey with null=True

On Thu, 2010-12-16 at 10:10 -0800, tonnzor wrote: > My idea was to fix this in a very straight way - change ForeignKey > behavior (the piece of code that generates many_set method) - so it > doesn't take into account null. > > Let me explain a bit more. If foreign key is nu

Re: ForeignKey with null=True

My idea was to fix this in a very straight way - change ForeignKey behavior (the piece of code that generates many_set method) - so it doesn't take into account null. Let me explain a bit more. If foreign key is null - then there's no link between Many and One object. So it many_set sho

Re: ForeignKey with null=True

3) the current behaviour is inconsistent with ManyToMany fields - they already do the checks that ForeignKey lookups are not doing. There is in fact one test in the test suite that breaks if we change this - it does Poll().choice_set.all() and expects an empty set. The reason it does this is to i

ForeignKey with null=True

Dear all, I have a model with a foreign key with null=True: class Many(Model): ForeignKey(One, null=True) class One(Model): pass Now if I do: one = One() ... then: one.many_set.all() ... returns all Many's with 'self.one_id == None&

Re: Call for review and comment: #7539 (ForeignKey on_delete)

_/-o_ \o/ On Nov 9, 5:59 pm, Carl Meyer wrote: > This is committed as r14507:http://code.djangoproject.com/changeset/14507 > > Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@goo

Re: Call for review and comment: #7539 (ForeignKey on_delete)

This is committed as r14507: http://code.djangoproject.com/changeset/14507 Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send e

Re: Call for review and comment: #7539 (ForeignKey on_delete)

Last call for any concerns with the patch; planning to land it in the next 24 hours. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this gro

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 6:51 pm, Gabriel Hurley wrote: > 1. Add the versionadded directive to "docs/topics/db/queries.txt", and > "docs/ref/contrib/contenttypes.txt". For reference, you can make it > very clear what was changed/added by using the following syntax (note > the *single* line break between the ve

Re: Call for review and comment: #7539 (ForeignKey on_delete)

> Another documentation-related question I have; is it necessary to mark > each passing referencing (and link) to on_delete with the version- > added marker? I went back and forth, and eventually decided against > it, for these reasons: (1) The passing references don't provide enough > info to use

Re: Call for review and comment: #7539 (ForeignKey on_delete)

rasing there is correct. PROTECT is an oddball because it _does_ actually prevent deletion of the referenced object; by raising IntegrityError it vetos the entire deletion, rather than allowing its ForeignKey to become invalid or changed. If you have specific suggestions for where the wording could be

Re: Call for review and comment: #7539 (ForeignKey on_delete)

rves a shoutout here. He was the original driving force behind this ticket, as was actively involved during the 1.2 development cycle. > Quick feature summary: the patch adds an on_delete argument to > ForeignKey (and, by extension, OneToOneField). This argument can be > set to any of the followi

Re: Call for review and comment: #7539 (ForeignKey on_delete)

ilable as a github branch; the compare view [2] presents it nicely > as a diff with trunk. The patch is mostly the (excellent) work of > Johannes Dollinger, with some additional work by myself and Alex > Gaynor. > > Quick feature summary: the patch adds an on_delete argument t

Call for review and comment: #7539 (ForeignKey on_delete)

with trunk. The patch is mostly the (excellent) work of Johannes Dollinger, with some additional work by myself and Alex Gaynor. Quick feature summary: the patch adds an on_delete argument to ForeignKey (and, by extension, OneToOneField). This argument can be set to any of the following: - CASCADE

Re: Feature request: ForeignKey through parameter

On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries wrote: > I quite often reference foreign keys of foreign keys of foreign keys... > Wouldn't it be nice to have a 'through'-parameter for ForeignKey's? > >    class A(Model): >        b = ForeignKey('B&#

Re: Feature request: ForeignKey through parameter

if B has more than one ForeignKey('C') fields? -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send em

Re: Feature request: ForeignKey through parameter

s A(Model): b = ForeignKey('B') c = ForeignKey('C', through='B', related_name='a_set') class B(Model): c = ForeignKey('C') i'd love such a feature too, but i think a better syntax could be something like: class A(Model):

Re: Feature request: ForeignKey through parameter

On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries wrote: > I quite often reference foreign keys of foreign keys of foreign keys... > Wouldn't it be nice to have a 'through'-parameter for ForeignKey's? > > >    class A(Model): >        b = ForeignKey('

Feature request: ForeignKey through parameter

Dear all, I quite often reference foreign keys of foreign keys of foreign keys... Wouldn't it be nice to have a 'through'-parameter for ForeignKey's? class A(Model): b = ForeignKey('B') c = ForeignKey('C', through='

Re: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

Alright. I filed it as #13871 under contrib.admin because I do not understand the larger issue, but please update it as you see fit. Thanks, Jeremy. Ticket Link: http://code.djangoproject.com/ticket/13871 -- You received this message because you are subscribed to the Google Groups "Django deve

Re: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

On Thu, Jul 1, 2010 at 12:40 AM, chadc wrote: ... > The jist of what I am wondering is if the changelist is going to allow > editable ForeignKeys, should it be caching the choices rather than > hitting the database every time? Yep, your models and explanation are clear. I'm not sure that CachedS

Re: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

han hitting the database every time? On Jun 29, 7:14 pm, Jeremy Dunck wrote: > On Wed, Jun 30, 2010 at 2:04 AM,chadc wrote: > > ... > > > 3. Overriding the ForeignKey widget with a custom CachedSelect widget. > > ... > > > PS: For the sake of posterity, I have incl

Re: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

On Tue, Jun 29, 2010 at 6:04 PM, chadc wrote: > Hi there, > > I have been experiencing poor performance with django-admin when > list_editable includes ForeignKey fields. In particular, rendering the > changelist requires O(m*n) database queries where m is the number of >

Re: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

On Wed, Jun 30, 2010 at 2:04 AM, chadc wrote: ... > 3. Overriding the ForeignKey widget with a custom CachedSelect widget. > ... > > PS: For the sake of posterity, I have included the code for my > CachedSelect widget. Yes, I am aware that using regular expressions to > parse

contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

Hi there, I have been experiencing poor performance with django-admin when list_editable includes ForeignKey fields. In particular, rendering the changelist requires O(m*n) database queries where m is the number of ForeignKey fields included in list_editable and n is the number of rows in the

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

and it hasn't been loaded from the DB I don't expect Django handling the ForeignKey attribute specially just as Django wouldn't prevent me setting a null=false IntegerField to a string or to null or throwing an exception when I access an attribute that hasn't been initialize

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On 12.02.2010 14:01, Tom Evans wrote: > I think the easiest way of understanding the behaviour is that > specifying a field like this: > >owner = models.ForeignKey(Owner) > > specifies a contract. The contract says that when you access this > attribute on an instance, it will only return an i

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On 12.02.2010 13:39, Russell Keith-Magee wrote: > > Hopefully that clarifies why Django works the way it does. Yes, it does. Thank you, Russel. > However, > even if, hypothetically, we were to accept that Django's current > behavior is in error, (...) there is an enormous issue of practicality.

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On 12.02.2010 12:08, Gary Reynolds wrote: > > Are you saying that the correct behaviour is to throw an IntegrityError > as opposed to a DoesNotExist on accessing the field? No. It should raise no exception at all. The expression should yield None. It should not be forbidden for an instance to con

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

I think the easiest way of understanding the behaviour is that specifying a field like this: owner = models.ForeignKey(Owner) specifies a contract. The contract says that when you access this attribute on an instance, it will only return an instance of an Owner object or raise an DoesNotExist

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On Fri, Feb 12, 2010 at 3:47 PM, Luc Saffre wrote: > Sorry, but the longer we discuss, the more it becomes clear: Django's > behaviour is certainly wrong. No, it really isn't *certainly* wrong. It's *arguably* wrong, and I join my colleagues Luke and Karen in arguing that it isn't wrong at all.

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

> > The correct exception is risen when you try to save it: > > >>> t.save() > Traceback (most recent call last): > ... > IntegrityError: 20100212_thing.owner_id may not be NULL > > How can you not understand that the DoesNotExist exception above is > risen too early? It is a bug! > Are you sa

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

Sorry, but the longer we discuss, the more it becomes clear: Django's behaviour is certainly wrong. I'm puzzled how no Django core developer seems to understand it. I hope that this is just because they are not following this thread because there is admittedly more urgent work to do right now. Wi

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On 10 fev, 12:42, Luc Saffre wrote: > Thank you, Henrique, for dropping in. > > Django's current behaviour is not correct because it forces me to access > non-nullable FK fields differently than nullable ones. "In Python, > throwing exceptions for expected outcomes is considered very bad form" > [

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

Thank you, Tamas. Yes, that's what I mean. Without you I might have come to believe that something is wrong with my brain... And yes, I can live with it. It's just a pity that others will stumble on it just because it isn't documented. Luc On 10.02.2010 19:30, Tamas Szabo wrote: > Hi, > > Well,

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

; learning Django while deploying with a legacy database. > > > > On 8 fev, 20:31, Luc Saffre wrote: > >> You cannot ask user code to not even look at invalid data. I'm > >> not allergic to exceptions, but raising an exception when I ask for the > >> conte

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

ate behaviour. >> >> Luc > > Raising the exception *is* appropriate behaviour, because when you > access `a_model.b_related`, and `b_related` is a ForeignKey, you're > not really accessing a value, but doing a lookup. This is consistent > with both the ER and ORM model,

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

Thanks, Karen, for your explanations which are very clear. I accept the community's decision and won't bother you any longer. And maybe one day I will even understand why this behaviour is not odd. Luc On 9.02.2010 17:03, Karen Tracey wrote: > On Tue, Feb 9, 2010 at 3:02 AM, Luc Saffre

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

n I ask for the > content of a field is not appropriate behaviour. > > Luc Raising the exception *is* appropriate behaviour, because when you access `a_model.b_related`, and `b_related` is a ForeignKey, you're not really accessing a value, but doing a lookup. This is consistent with

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On Tue, Feb 9, 2010 at 3:02 AM, Luc Saffre wrote: > "Closed" as "Invalid", as I understand it, means that this ticket is not > worth to get more consideration and that further comments are not welcome. > > "Open" with a triage stage of "Someday/Maybe" would help people who > stumble on this behav

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On 9.02.2010 1:09, Karen Tracey wrote: > On Mon, Feb 8, 2010 at 5:31 PM, Luc Saffre > I personally won't insist > further, especially since Luke knows Django better than me. May I > suggest again to mark this ticket to something different than "duplicate > of an invalid ticket"? >

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On Mon, Feb 8, 2010 at 5:31 PM, Luc Saffre wrote: > [snip] Okay, it's obvious that Luke's and Luc's understandings of that problem > are quite different. We both explained our points of views. The next > step would be to hear other people's opinions. > I agree with Luke. I'm also puzzled by you

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

> not accidental, but quite deliberate. I admit that I am surprised to hear this. > The behaviour is only odd from > one angle, and it is not very strange, because ForeignKey fields *are* > a fundamentally different type of field. The corresponding 'normal' > field is t

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On Sunday 07 February 2010 04:07:22 Luc Saffre wrote: > Luke, I disagree with your explanations. Django behaves oddly. > > Model.save() is the place where empty non-nullable fields cause an > exception. > There is no reason for ForeignKey to behave differently. > ForeignKey fi

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

On 7.02.2010 3:06, Luke Plant wrote: > 1. ForeignKey fields are different from simple values, in that they > cause database lookups (the only logical exception being nullable > foreign keys with a PK of None), so it's reasonable for them to behave > differently. Luke, I d

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

n. The issue is what should happen with the following model: >>> class Foo(Model) >>> a_date = DateTimeField() >>> bar = ForeignKey(Bar) >>> >>> f = Foo() >>> f.bar The current behaviour is that a 'DoesNotExist' exception is thrown

#12801 : Allow empty non-nullable ForeignKey fields until save()

Hello, I am trying to understand why Luke closed my ticket #12801 (http://code.djangoproject.com/ticket/12801). Luke, don't get me wrong. Thank you for having taken the time to decide upon this and my other ticket #12708. I agreed with you for marking #12708 as invalid, because I didn't understan

Re: Adding ForeignKey to model alters SQL generated for ManyToManyField in model

On Sep 25, 11:23 am, Ramiro Morales wrote: > > I suspect there is a clash between the names of your m2M and FK fields > (category, category_id), try changing one of them so there isn't one > relationship field with a name equal to the name of the other plus > '_id'. > > Note that I'm not saying t

Re: Adding ForeignKey to model alters SQL generated for ManyToManyField in model

ory', >        db_table='map_cms_consumer_reports_to_category', >        verbose_name='Associated categories', >        help_text='Select all categories related to this report') > > [...] > > If, however, I add the following ForeignKey to the model, and

  1   2   >