Re: Renaming apps.has_app
On 06/01/14 00:26, Aymeric Augustin wrote:
> On 5 janv. 2014, at 22:54, Shai Berger wrote:
>
>> I'd go for __contains__:
>>
>> if "django.contrib.auth" in apps:
>
> I considered this one but I didn’t select it because it will restrict our
> freedom in the future.
>
> If I were to add magic methods on the app registry I’d probably make it a
> dict of app_label => app_config. This is the most common use case.
>
> Then it would be inconsistent to support `if "django.contrib.auth" in apps`
> and `apps['admin']` at the same time.
>
+1 for is_installed.
And I like your plan to make apps behave as a dict of app_label =>
AppConfig instances. When you want to test for a full app name, use
if apps.is_installed('django.contrib.admin'): ...
If you don't care about the full path and want to test for the
app_label, then use
if "admin" in apps: ...
Aymeric, you are really talented! Thanks for your work!
Luc
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/52CA1044.9010708%40gmx.net.
For more options, visit https://groups.google.com/groups/opt_out.
Re: App-loading reloaded
On 26/12/13 11:47, Aymeric Augustin wrote: > On 26 déc. 2013, at 00:22, Luc Saffre wrote: > >> But your implementation is more beautiful than mine, and I'm looking >> forward to retire my djangosite project as soon as possible. > > I wouldn’t say “beautiful” as much as “minimal”. Django’s core must be > extremely conservative when it comes to assumptions about how it will > be used. Also, being allowed to change the internal helps ;-) > > Your App class contains more data. It is CMS-oriented, with stuff like > site_js_snippets. You should look into inheriting AppConfig. I agree 100% (except that "beautiful" includes "minimal"). In fact I was planning to do that (move the site_js_snippets stuff away from djangosite.App and add it only in Lino). >> OTOH djangosite adds another concept, about which you do not seem to >> speak: I currently call it a "Site" class, but to stay with your >> terminology we might also call it a "ProjectConfig" class. > > This concept is more or less represented by the settings module and by > a bunch of classes such as Apps or ConnectionHandler that are directly > derived from some settings. > > I don’t know if it’s a very good design but it has the advantage that you > can use Django as a library without having to call an arbitrary method > (e.g. django.startup()) first. Thanks for your feedback. Indeed, the `djangosite.Site` class was there before `djangosite.App`, and maybe I'd now implement these things using one or several `AppConfig` subclasses. If one day I find a clear example why a "ProjectConfig" class would be necessary, I'll share it. Meanwhile thanks to you and all those working on Django. Luc -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/52BC3FD3.2020609%40gmx.net. For more options, visit https://groups.google.com/groups/opt_out.
Re: App-loading reloaded
On 24/12/13 12:23, Aymeric Augustin wrote: > > Of course I’m happy to provide feedback and supervision to > contributors who’d like to tackle some of these items. Just get in > touch before you start coding to avoid duplicate work. Hey Aymeric, thanks for your work! I am not a core developer, but feel proud to see that Django "finally realizes" something I have always been preaching (admittedly only in my corner). I have written something almost similar. Your `AppConfig` corresponds to my `App` class in https://github.com/lsaffre/djangosite/blob/master/djangosite/djangosite_site.py But your implementation is more beautiful than mine, and I'm looking forward to retire my djangosite project as soon as possible. OTOH djangosite adds another concept, about which you do not seem to speak: I currently call it a "Site" class, but to stay with your terminology we might also call it a "ProjectConfig" class. http://site.lino-framework.org/usage.html http://site.lino-framework.org/application.html I agree that my project is not very well documented, but I believe that my work might be useful for Django, and I am ready to share it and to help as much as possible in case you are interested. Luc -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/52BB68AC.3010004%40gmx.net. For more options, visit https://groups.google.com/groups/opt_out.
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 instance of an Owner > object or raise an DoesNotExist exception. > > Specifying a field like this: > > owner = models.ForeignKey(Owner,blank=True,null=True) > > specifies a very different contract. This contract says that accessing > this attribute will return either an instance of an Owner object, or > None if no owner has been specified. > > Both contracts are fully described in the documentation and fulfilled > by the ORM, so clearly this is no bug. Both flavours are available for > you to use, you simply have to decide what sort of contract you want > that attribute to have - if you expect instance.owner to return None, > then clearly you should be using a nullable foreign key. Wow! This formulation is really clear. Thank you, Tom. My summary: Django's behaviour is un-pythonic and not the most elegant one, but it is possible to get used to it, even to rely on it, and it certainly won't change. I didn't find such a good explanation in the docs, though. IMHO it should be here: http://docs.djangoproject.com/en/dev/topics/db/queries/#forward I suggest to add a paragraph about the surprising DoesNotExist there. Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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. > (...) > Although the > change would be a minor code modification, it would be *very* > complicated to change it in practice, given Django's API backwards > compatibility guarantee. And as a result, we're *not* going to change > it. Yes, this is a good reason to not change Django's behaviour, independently of whether it is "wrong" or not. Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 contain invalid data *until* you try to save it. > If so, why would accessing a value on an unsaved instance (which by > definition isn't in the database yet) be an IntegrityError rather than a > DoesNotExist as a result of a lookup? > > It's clearly a design decision. You are free to disagree with that > decision, but it's not a bug - it's behaving as designed (and documented). If this is a topic that has been discussed earlier, then it would be good to find pointers to this discussion. I didn't find any. If at least one core developer would say "maybe Luc is right", then Luke and Karen would maybe agree to reopen the ticket and mark it "needs design decision". And please: I continue to post here because I hope that my explanations can help to understand the problem and to make Django better. I don't want to offend anybody, I am not trying to "win" this "battle", I have no personal interest in having this ticket reopened. If some day I understand that *I* was wrong, then I will apologize for the noise I made. Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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. With the danger of repeating myself I explain once more: Example models: class Owner(models.Model): pass class Animal(models.Model): # nullable owner owner = models.ForeignKey(Owner,blank=True,null=True) class Thing(models.Model): # non-nullable owner owner = models.ForeignKey(Owner) There should never be a related lookup when the fk_id is None. For nullable FK Django behaves correctly: >>> a = Animal() >>> print a.owner None The same doesn't work for non-nullable FK: >>> t = Thing() >>> print t.owner Traceback (most recent call last): ... DoesNotExist This is whay I say that Django treats non-nullable FK in a special way. It is as if Django thinks "Since Thing.owner may not be None, I can do the lookup without even testing for a None value". 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! Luc On 12.02.2010 6:24, hcarvalhoalves wrote: > 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" >> [1]. Django should raise an exception only if I try to save an instance >> with invalid data (for example None in a non-nullable FK field), but not >> when I try to access any data, may it be valid or not >> >> Luc > > The exception doesn't come from the fact you're accessing an > attribute. It comes from the related lookup, Django is just doing the > right thing and letting the DoesNotExist exception flow up. It's > better if you see things this way. > > Also, the DoesNotExist exception is far from undocumented. Thru the > docs and tutorials you see the idiom on how to handle it quite a few > times. [1] > > It also makes perfect sense to handle nullable FK's different than non- > nullable ones. One have a constraint imposed, the other not. Returning > None to a non-nullable FK, *this* would be what I call unexpected > behaviour. > > Remember also that this is not a pure OO world. If we were seeing > things as just relations between classes, I would agree with you. But > we're dealing with a cumbersome thing that is the database, and > there's always a mismatch between the ER and OO models. [2] > > Anyway, there's certainly nothing wrong or strange on throwing > exceptions on accessing attributes in Python (or in any dynamic > language, I would say), as any attribute on Python can be, in fact, a > method (@property). I'm surprised how opposing you feel on this, my > feeling is that you come from a different background, working with > languages that enforce exception handling in a special way (Java, C#). > But it's really getting into the field of personal taste now. > > [1] http://docs.djangoproject.com/en/1.1/ref/models/querysets/#id5 > [2] http://www.sbql.pl/Topics/ImpedanceMismatch.html > -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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, I'm not a django core developer, so my post probably won't weight > that much, but I can't leave Luc with the feeling that that aren't other > people that have the same opinion as him. > Luc, I'm with you on this one :) > > First of all the problem is in an area of handling the mismatches > between the OO and the relational models, an area that should always > cause discussions. So, Luc I guess you have to accept that this is a > gray area and this is how Django's ORM works. Life goes on ... > > On the other hand, I do not understand how you can't see the point that > Luc is making and how can you say that this makes sense from both the ER > and ORM point of view. When you are working with your OO model the > relationship between your models aren't represented by FK pointers. They > should map to attributes of models or collections of models. > FK based relations from the DB are represented by attributes and > collections in the OO world and the ORM should take care of this mapping > and making it transparent. > > In an ideal world you shouldn't use or even know about those _id fields > when working with your OO models. > Your working with your OO domain model that consists of Python classes > and they should work like any other normal Python classes until you use > save or load them (then the ORM kicks in and does the mapping). > But until you do that, they should behave like Python classes so > throwing DoesNotExist Exception when you access an attribute of a class > feels a little bit strange. > > But of course our world is more pragmatic and I can live with the > current implementation (and I hope Luc can do the same), but I can > certainly understand why it feels strange to him and why he resists > using _id fields while working with his models. > > All The Best, > > Tamas > -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: What The Enterprise wants from Django
On 19.01.2010 23:26, Jacob Kaplan-Moss wrote: > Finally, we ruminated over the difficulties in building rich internet > applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine, > but we doesn't really have a good answer for the people who want > something IDE or GUI-ish. Meanwhile, Adobe and Microsoft are putting > all sorts of marketing dollars into Flex/Silverlight, and although > HTML5 can do some amazing things, the lack of tooling is a big danger. > (I've written at more length about this in the past: > http://jacobian.org/writing/snakes-on-the-web/#s-rich-web-applications). It's a bit early to speak about Lino, but Jacob's post incited me to write a kind of preview for Django developers: http://code.google.com/p/lino/wiki/LinoAndDjango Encouraging words are welcome now, but wait a few months before you seriously investigate this project. Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
Thank you, Henrique, for dropping in. As I said earlier, I don't want to bother the community with my stubbornness or whatever it may be, so feel free to STOP READING HERE if there is danger that this topic wastes your time. But to be honest, I must unfortunately say that I disagree also with your explanations and that they (for me) confirmed my opinion. The expression `a_model.b_related` (where `a_model` is an instance of a Model subclass that defines a field `b_related`) must always yield a value in the Pythonic meaning (that is, it may yield None which is also a value in Python). This same expression should raise an exception only if the field name is wrongly spelled, or if an error occured when constructing the related instance to be yielded (e.g. a failed DB lookup in the case of a FK field other than None). A FK containing None (which is already now possible for nullable FK fields) will never cause a DB lookup. Django guarantees that the value of a FK field will always be either None or an instance of the related Model. Django never guaratees that every instance of a Model exists as a row in the database. 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" [1]. Django should raise an exception only if I try to save an instance with invalid data (for example None in a non-nullable FK field), but not when I try to access any data, may it be valid or not [1] http://groups.google.com/group/comp.lang.python/browse_thread/thread/7d6191ecba652daf Luc On 10.02.2010 6:28, hcarvalhoalves wrote: > Maybe I can help Luc? I had similar questions once, because I started > 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 >> 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 both the ER and ORM model, where FK's are pointers, not values. > And a FK pointing to a non-existant row *is* an exception. It means > broken data. > > If you want the content of the *field*, what you really should check > is `a_model.b_related_id is None`, which is checking if a pointer was > set. Still, it doesn't guarantee that this pointer leads to anywhere > valid. That's why dealing with the exception is a common idiom, "fail > early, fail loudly", and particularly useful in this case to maintain > DB consistency. > > I hope it helps in understanding the rationale behind the behaviour > and why Luke marked as invalid. > -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 <mailto:luc.saf...@gmx.net>> 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 behaviour to find our discussion. Especially if we add a > link to this discussion thread. > > > Open with a triage state of Someday/Maybe would imply that the current > behavior has been acknowledged as wrong and that a change in the > behavior might be expected. It would also imply that if someone provided > a patch to change the behavior, it would have a chance of getting > checked in. With two core devs stating they see the current behavior as > logical and consistent and none stepping up to say the opposite, a > change in behavior here isn't going to happen. Thus an open state for > this ticket would give people the wrong impression of the state of the > issue. > > Closed tickets are as easily found as open ones -- anyone doing research > in an attempt to understand current behavior should not be limiting > their searches to only open tickets. > > The right state for this ticket is closed, which means it's been > reviewed and determined that the current behavior is correct and nothing > needs to be done to fix it. I would not term further comemnts > "unwelcome", but they are not particularly useful unless someone has > some new light to shed on the issue. > > Karen > > -- > 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 email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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"? > > What difference does it make? "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 behaviour to find our discussion. Especially if we add a link to this discussion thread. Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
Luke, thank you for your explanations. If I answer once more, then I do it in the hope that our discussion may help to improve Django. On 8.02.2010 0:38, Luke Plant wrote: > It is easy to fix - a few lines in > ReverseSingleRelatedObjectDescriptor - because the behaviour there is > 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 the '_id' field - this is a dumb value. Sorry, but I still don't understand the angle from which this behaviour is *not* odd. And the corresponding '_id' field is added 'behind the scenes', so using it should be avoided as much as possible. > I think you are missing the fact that this behaviour occurs *whenever* > the FK val is an invalid value, not just with creating new instances. No, I considered this. I wrote already the two possible causes of exceptions that I can imagine. > You are therefore asking either for special treatment of instances > that are not saved to the database, or for it to be broken in general. That's no special treatment. I'm asking to have the same behaviour for nullable and non-nullable ForeignKey fields (until save()). Having 'None' in a non-nullable field is a normal case of an instance containing invalid data. Imagine an application that runs a complex series of handlers on an instance that decide how to set some fields depending of the (valid or invalid) values contained in some other fields. 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 content of a field is not appropriate behaviour. > Consider this code: > o = SomeModel.objects.get(id=1) o.fk_field_id = None print o.fk_field > > Are you are proposing that the above should print 'None' even when > fk_field is non-nullable, rather than a DoesNotExist? Yes. Though I'd say "o.fk_field = None" instead of "o.fk_field_id = None", because the '_id' field should remain behind the scenes. Anyway both should have the same effect. > 'o.fk_field' is > a shortcut for a DB lookup of 'o.fk_field_id', and clearly the result > of that lookup is *not* None/NULL. The query returns no results, and, > just like every other case when a query returns no results and we > expect at least one, you get a DoesNotExist exception. (In this case > we skip doing the actual database query as an optimisation, but the > same logic applies). 'o.fk_field' is an attribute of a Model instance, and Django should never refuse to show what it contains, even if that value is illegal. 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 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"? Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 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 fields are different in that they cause database lookups when they are not None, and that they can cause exceptions in some special situations, for example - asking them to save before the foreign instance has been saved - database integrity errors (invalid non-None pk) That said, it is clear that I don't know Django well enough to decide whether it is feasible/necessary to fix this odd behaviour. Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#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 understand the real problem when I wrote it, so the formulations in that ticket are rather confusing. But #12801 now shows so clearly an odd behaviour which should at least be documented if it cannot be fixed. Marking #12801 as a duplicate of an invalid ticket means to me that I should not even *try* to write a patch. Is that really what you want to say? I'd agree if you say that this is not an urgent problem. But shouldn't we mark it then as "Someday/Maybe"? Luc -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: multitable inheritance - child doesn't accept parent link
On 18.06.2009 14:05, Ramiro Morales wrote: > > Why do you thing there should be a automatically created one to one > relationship from Customer to Contact named "contact"?. Why I think there should be a automatic one-to-one relation from Customer to Contact? Because that's what the MTI documentation says (as far as I understand it): > Specifying the parent link field > > As mentioned, Django will automatically create a OneToOneField > linking your child class back any non-abstract parent models. If you > want to control the name of the attribute linking back to the parent, > you can create your own OneToOneField and set parent_link=True to > indicate that your field is the link back to the parent class. http://docs.djangoproject.com/en/dev/topics/db/models/#specifying-the-parent-link-field It's true that I didn't notice that the example (http://www.djangoproject.com/documentation/models/one_to_one/) isn't about MTI at all (rather a kind of emulation). Okay, when I add an explicit parent link in my example: contact = models.OneToOneField(contacts.Contact,parent_link=True) then the TypeError disappears. But still I would now expect that the following works: >>> c = Customer(contact=luc) >>> c.save() >>> c.last_name Saffre But it fails, saying: Failed example: c.last_name Expected: Saffre Got: '' It looks as if Django doesn't "copy" the values of the existing Contact into the Customer. The last_name field was inherited (it didn't say "AttributeError: 'Customer' object has no attribute 'last_name'") but it is empty. Note that I'm using Django development version, revision 11066... I guess that this is a bug and that it has to do with ticket #7623 (http://code.djangoproject.com/ticket/7623). Thus cc to django-developers and a new very short example showing the problem. (Should I wait for feedback from developers before opening a new ticket?) Luc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~--- """ Small example for the problem described in ticket #7623 (http://code.djangoproject.com/ticket/7623) With revision 11066, the following doctest fails:: Failed example: r Expected: Got: >>> p1 = Place(name='Demon Dogs') >>> p1.save() # Create a Restaurant from this Place. >>> r = Restaurant(place=p1, serves_hot_dogs=True) >>> r.save() >>> r """ from django.db import models class Place(models.Model): name = models.CharField(max_length=50) def __unicode__(self): return self.name class Restaurant(Place): serves_hot_dogs = models.BooleanField() # the following explicit parent_link should not be necessary according to # http://docs.djangoproject.com/en/dev/topics/db/models/#specifying-the-parent-link-field place = models.OneToOneField(Place,parent_link=True)
