Field.to_python() clarification
The docs say about Field.to_python(): """ As a general rule, the method should deal gracefully with any of the following arguments: * An instance of the correct type (e.g., Hand in our ongoing example). * A string (e.g., from a deserializer). * Whatever the database returns for the column type you're using. """ I understand that the first rule is useful when using the SubfieldBase metaclass, so that ``obj.field = value`` works both for serialized/DB values and instances of the correct type. Other than this case, is to_python() called anywhere else in the framework with a value that may already be of the correct type ? IOW, if I define a custom field without using the SubfieldBase metaclass, do I still have to handle converted Python objects ? The reason I'm asking is that it is not always easy or possible to differentiate between converted and unconverted values. For example a field that tries to encode Python objects to JSON doesn't have a way to differentiate between encoded JSON strings and unencoded strings that just happen to be valid JSON. All JSONField implementations I have seen (e.g. http://www.djangosnippets.org/snippets/1478/) use essentially a best-effort approach, "try to decode it and if it fails assume it is already decoded", which is generally error prone. I have a different approach that doesn't use SubfieldBase and expects unconverted values to be passed in to_python(), so I'd like to know whether this expectation is always true. George -- 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: High Level Discussion about the Future of Django
On Apr 15, 8:57 pm, Kevin Howerton wrote: > The level of resistance I see to change or outsider code contribution > is an enormous de-motivator for people (like me) to want to make any > contributions in the first place. Why should I contribute a patch to > your flawed architecture if I'm going to be talked down to, ridiculed, > then eventually have the patch rejected because it breaks code in some > edge-use-case? Good luck pushing backwards incompatible patches when as we speak there are almost 400 open tickets with patches at accepted [1] and "ready for checkin" [2] stage. Under these circumstances, backwards compatibility is almost a red herring; the bigger issue IMO is the increasing pile of bug fixes and solid, backwards compatible patches languishing for months or years. A fork that encouraged and achieved a faster submit-review-accept- commit lifecycle, even with the same stability, maturity, and longevity policies, could be a breath of fresh air. George [1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=!1&needs_tests=!1&needs_docs=!1&has_patch=1&order=priority&stage=Accepted [2] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=!1&needs_tests=!1&needs_docs=!1&has_patch=1&order=priority&stage=Ready+for+checkin -- 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: High Level Discussion about the Future of Django
On Apr 15, 8:57 pm, Kevin Howerton wrote: > The level of resistance I see to change or outsider code contribution > is an enormous de-motivator for people (like me) to want to make any > contributions in the first place. Why should I contribute a patch to > your flawed architecture if I'm going to be talked down to, ridiculed, > then eventually have the patch rejected because it breaks code in some > edge-use-case? Good luck pushing backwards incompatible patches when as we speak there are almost 400 open tickets with patches at accepted [1] and "ready for checkin" [2] stage. Under these circumstances, backwards compatibility is almost a red herring; the bigger issue IMO is the increasing pile of bug fixes and solid, backwards compatible patches languishing for months or years. A fork that encouraged and achieved a faster submit-review-accept- commit lifecycle, even with the same stability, maturity, and longevity policies, could be a breath of fresh air. George [1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=!1&needs_tests=!1&needs_docs=!1&has_patch=1&order=priority&stage=Accepted [2] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=!1&needs_tests=!1&needs_docs=!1&has_patch=1&order=priority&stage=Ready+for+checkin -- 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: High Level Discussion about the Future of Django
On Apr 17, 5:35 am, "Tom X. Tobin" wrote: > On Fri, Apr 16, 2010 at 10:10 PM, Russell Keith-Magee > > wrote: > > However, at this point, I would like to tell you a story about four > > people named Everybody, Somebody, Anybody, Nobody. > > This is exactly why I try not to bitch too much about Django's > development process. It's very easy to complain, but it's not quite > so easy to "shut up and show me the code". My point is that unfortunately this is not enough. The 400 languishing patches have been submitted by people who did exactly that, they "shut up and showed the code", possibly without ever complaining in this list. And not only that but their patches (or some percentage of them at any rate) have been "accepted" or became "ready for checkin" at some point. How come a developer finds the time to review a patch, accept it, consider it ready for checkin but not actually commit it ? Healthy projects don't need a separately maintained fork/branch on github or bitbucket just to review and apply patches. They open up their gates and they invite more contributors to the development process (in a controlled manner of course) so that they can keep up with the increasing volume of external contributions. George -- 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: High Level Discussion about the Future of Django
On Apr 17, 3:47 pm, Russell Keith-Magee wrote: > For the record, there are 62 tickets marked ready for checkin, not 400 > [1]. 29 of those are documentation and translation patches (5 of which > are specifically marked for inclusion in 1.2). > > [1]http://code.djangoproject.com/query?status=new&status=assigned&status... > > On top of that, the Ready For Checkin status doesn't mean that a > member of the core team has reviewed a patch. It means that someone -- > anyone -- thinks the patch is ready for checkin. There's no guarantee > that a Ready For Checkin patch is *actually* ready for checkin. If you > do a survey of the Ready For Checkin patches, you'll find tickets that > don't have test cases, or add features that aren't documented, or make > a significant changes that haven't been discussed on django-dev. If I > were to sit down and work through that list, I guarantee I wouldn't > end up making 62 commits to trunk using the material that has been > provided on those tickets. If the tracker fields are not to be trusted as authoritative, why give public access to them in the first place ? The Python tracker allows only developers to modify most fields, I guess Trac should have a way to control access too. > I would also point out the folly of looking at raw ticket counts. > Python (the language) has 1078 tickets in the "having patch" status, > and 96 in the "needing review" status. Does this mean that Python is a > project in crisis? For the record, if you count all tickets with patches, then Django has 992 (they drop to 616 after excluding those that need improvement, documentation and tests and to 406 when considering only the "accepted" and "ready for checkin" stage - assuming these numbers mean anything). That's pretty close to the ticket count of a much larger in size and complexity project. Speaking of Python (the language) contribution process, I had the recent pleasant experience of having a patch of mine accepted for Python 2.7. It's not a bug fix, it's a new feature and so it could have easily been ignored, postponed after the release or simply dismissed as unnecessary but it wasn't; within two weeks since the original submission and with great responsiveness and feedback from the core dev that reviewed it, it was committed a few days before the first beta. Quite a different experience from Django. > My dream outcome would to be in the situation where I don't *ever* > have to spend time on Trac trying to work out if the ticket that has > been marked Ready For Checkin is *actually* ready for checkin. Give me > a rich vein of trunk ready tickets that has been reviewed by someone > whose reputation I know and trust, and believe me -- I will use it. Again, unless there is a good reason for giving public access to all fields, make them accessible only to trusted members and let the official tracker become this rich vein of trunk ready tickets. Even if nothing else changes, we should at least be able to trust the report counts and have a more accurate view of the project's status. > > Healthy projects don't need a separately maintained fork/branch on > > github or bitbucket just to review and apply patches. They open up > > their gates and they invite more contributors to the development > > process (in a controlled manner of course) so that they can keep up > > with the increasing volume of external contributions. > > The flipside of this is that too many cooks spoil the broth. If we > want to maintain a high quality product, we can't just add a dozen new > developers to the core team. > > I would also point out that even in projects that do have large teams > with the commit bit, access to the "core trunk" is generally only made > available to a restricted subset of the entire team. Alternatively, > some sort of code review process is used to ensure that multiple team > members (occasionally, specially blessed team members) check patches > before they are committed. There's a lot more to commit policies in > open source than raw team size. Agreed, that's why I stressed "in a controlled manner". The question is what prevents the influx of new skilled and trustworthy blessed members, the institution of code review policies and everything else that a large project needs to flourish. George -- 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.
Silently replaced session_key
Is this a bug or a feature ? >>> from django.contrib.sessions.backends.db import SessionStore >>> s = SessionStore(session_key='secret!!!11') >>> s.session_key 'secret!!!1!1' >>> 'foo' in s False >>> s.session_key '7f9aa956cb169b1f89a3a5b384cafc1b' George -- 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: Silently replaced session_key
On May 4, 11:05 pm, Jacob Kaplan-Moss wrote: > On Tue, May 4, 2010 at 3:11 PM, George Sakkis wrote: > > Is this a bug or a feature ? > > Take a look at the source (django/contrib/sessions/backends/db.py; > line 16 - the load() function). If the session key doesn't exist in > the database, a new session key will be generated. This prevents users > from being able to "choose" arbitrary session keys, so that's the > correct thing to do. Ok, the rationale makes sense (as a default, overridable choice at least) but the API could be less surprising, e.g. raise an exception when a non auto-generated key is passed. Also it turns out that it doesn't really prevent setting a key explicitly, it just makes it more cumbersome: session_key = 'secret!!1!' s = SessionStore(session_key) s['foo'] = 'bar' s.session_key = session_key # I *really* mean session_key dammit s.save() This creates two entries, one with a random key and one with session_key but only the latter's session_data are updated. The following avoids creating the random key in the first place: s = SessionStore() if not s.exists(session_key): s['foo'] = 'bar' s.session_key = session_key s.save() I'm not sure if these are unintended implementation side effects but they seem incongruent. George -- 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: Silently replaced session_key
On May 5, 12:25 pm, Tom Evans wrote: > On Wed, May 5, 2010 at 10:24 AM, George Sakkis > wrote: > > On May 4, 11:05 pm, Jacob Kaplan-Moss wrote: > > >> On Tue, May 4, 2010 at 3:11 PM, George Sakkis > >> wrote: > >> > Is this a bug or a feature ? > > >> Take a look at the source (django/contrib/sessions/backends/db.py; > >> line 16 - the load() function). If the session key doesn't exist in > >> the database, a new session key will be generated. This prevents users > >> from being able to "choose" arbitrary session keys, so that's the > >> correct thing to do. > > > Ok, the rationale makes sense (as a default, overridable choice at > > least) but the API could be less surprising, e.g. raise an exception > > when a non auto-generated key is passed. Also it turns out that it > > doesn't really prevent setting a key explicitly, it just makes it more > > cumbersome: > > > session_key = 'secret!!1!' > > s = SessionStore(session_key) > > s['foo'] = 'bar' > > s.session_key = session_key # I *really* mean session_key dammit > > s.save() > > > This creates two entries, one with a random key and one with > > session_key but only the latter's session_data are updated. > > > The following avoids creating the random key in the first place: > > > s = SessionStore() > > if not s.exists(session_key): > > s['foo'] = 'bar' > > s.session_key = session_key > > s.save() > > > I'm not sure if these are unintended implementation side effects but > > they seem incongruent. > > > George > > If you allow users to present new session ids without replacing them, > then you open up an attack vector for a session fixation attack. The > default behaviour is default for a reason. I'm repeating myself here but if the intention is to really disallow user-provided ids. it can be done more clearly: raise an exception if the key does not exist and make the session_key property read-only. Now it seems like a bug that you can sort of work around by setting the key just before saving. By the way, this does not apply to all backends; file SessionStore for example uses passed ids as is. Whatever the desired behavior is, it should apply to all backends, so the relevant logic should move to SessionBase. George -- 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: Silently replaced session_key
On May 5, 10:20 pm, Jeremy Dunck wrote: > On Wed, May 5, 2010 at 2:45 PM, George Sakkis wrote: > > ... > > > I'm repeating myself here but if the intention is to really disallow > > user-provided ids. it can be done more clearly: raise an exception if > > the key does not exist and make the session_key property read-only. > > Now it seems like a bug that you can sort of work around by setting > > the key just before saving. > > Allowing an attacker to predictably raise exceptions might be bad. The exception would not propagate of course all the way up the stack, it would be caught by a caller that knows how to handle it (e.g. middleware). In this way SessionStore backends would be responsible only for the low level storage details, not the security policy. On second thought though this is probably impractical since load() is called implicitly the first time a dict-like method is called, so the exception could be raised almost anywhere the session is first accessed. George -- 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.
add() and remove() on ManyToManyField with through model
Maybe I'm missing something but I don't see why the lack of of remove() and add() for ManyToManyFields with 'through' model is necessary. For remove, the docs say "The remove method is disabled for similar reasons (to add)" but it's not clear why. All it is required for "beatles.members.remove(john)" to work are the two foreign keys; the extra data of the relationship are not needed. But even for add() the check is restrictive. For one thing, a through model might be defined just to add or override some methods, without any other fields than the two foreign keys. Or, more likely, all additional fields may not require initialisation (nullable, default, auto_now, etc.). These cases would just work without any change in the API. A backwards compatible change to add() would allow even extra required fields: "add(*objs, **relationship_attrs)". Thus the example in the docs: Membership.objects.create(person=paul, group=beatles, date_joined=date(1960, 8, 1), invite_reason= "Wanted to form a band.") could be written as: beatles.members.add(paul, date_joined=date(1960, 8, 1), reason= "Wanted to form a band.") Thoughts ? George -- 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: add() and remove() on ManyToManyField with through model
On Jun 11, 1:11 pm, Russell Keith-Magee wrote: > On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis > wrote: > > Maybe I'm missing something but I don't see why the lack of of > > remove() and add() for ManyToManyFields with 'through' model is > > necessary. > > > For remove, the docs say "The remove method is disabled for similar > > reasons (to add)" but it's not clear why. All it is required for > > "beatles.members.remove(john)" to work are the two foreign keys; the > > extra data of the relationship are not needed. > > > But even for add() the check is restrictive. For one thing, a through > > model might be defined just to add or override some methods, without > > any other fields than the two foreign keys. Or, more likely, all > > additional fields may not require initialisation (nullable, default, > > auto_now, etc.). These cases would just work without any change in the > > API. A backwards compatible change to add() would allow even extra > > required fields: "add(*objs, **relationship_attrs)". Thus the example > > in the docs: > > > Membership.objects.create(person=paul, group=beatles, > >date_joined=date(1960, 8, > > 1), > >invite_reason= "Wanted to > > form a band.") > > could be written as: > > > beatles.members.add(paul, date_joined=date(1960, 8, 1), reason= > > "Wanted to form a band.") > > > Thoughts ? > > This was discussed at the time that m2m-intermediate models were > added. If you want some of the history, see the ticket discussion on > #6095 (in particular, around here [1]). > > [1]http://code.djangoproject.com/ticket/6095#comment:31 > > There are are a couple of issues with the approach you describe. > They're not necessarily insurmountable issues, but they were enough of > a problem for us to make the decision to punt them until later in the > interests of delivering basic m2m-intermediate functionality. > > Now that we've been living with m2m-intermediates for a while (almost > 2 years), the time may be ripe to revisit these dangling issues. If > you want to make a proposal in this area, feel free to do so -- just > make sure you address the history when you do. It's not necessarily as > simple as just adding kwargs to the add() method. Thanks for the prompt reply! I skimmed through the ticket but I'm not sure I spotted any particularly unsolvable problems. Just to clarify, I am interested in the following three issues, more or less independently from each other: 1) remove(): The only related comment I read in the ticket is "There is an analogous problem with remove - since you can now have multiple relations between objects, a simple remove method is no longer an option.". But remove() is a method of a descriptor referring to a specific m2m relation, so it is clear to which one it refers to. E.g. in your example: a_group.club_membership.remove(a_person) # remove person from club_members a_group.team_membership.remove(a_person) # remove person from team_members. If the issue had to do specifically with the fact that that the same through model (Membership) was used between Group and Person more than once, I am not interested in allowing this; the current validation approach is fine. 2) add() for m2m-intermediates with only null/default/derived extra fields. If I'm reading your comments correctly, you were against adding null=True to fields that are not semantically nullable, just as a workaround for add(). I agree and I'm not suggesting adding nulls or defaults just for the sake of making add() work, but for fields that should accept null or a default regardless, why prevent them ? As for the implementation, I'm not suggesting any 'compile time' validation and introspection; just let any errors happen when add() eventually calls through.create(...). 3) add() for m2m-intermediates with required extra fields. The suggestion in the ticket is to pass an 'extra' dict argument; I'm fine with that instead of passing them as **extra; it has the added benefit it can be used in create() as well (although I'm less interested in allowing create). Fully agree with your comments about not adding more fine-grained, per-object extra arguments (you can always use multiple calls to add()) or an additional "add_extra" method. If there are any other issues I ignored, let me know and I'll be happy to consider them. George -- 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.
m2m_changed signal
I'm wondering what was the rationale for introducing a new separate
signal for m2m relationships, as opposed to using the existing ones on
the intermediate ('through') model. Currently the situations is
confusing:
* For m2m fields with auto_created intermediate model, calling
``Model.m2m_field.add/remove/clear`` sends m2m_changed. However adding/
removing relations using directly the through model (e.g.
``Model.m2m_field.through.objects.create(...)) does not send
m2m_changed. Adding handlers for pre/post_save, pre/post_delete on the
through model has no effect; the code specifically checks for
auto_created models and does *not* send these signals in this case.
* For m2m fields with a given intermediate model,
``Model.m2m_field.add/remove`` are not exposed (at least for now but
this is under discussion) and therefore m2m_changed is not sent;
instead you have to handle addition/removal in pre/post_save, pre/
post_delete handlers on the through model. However
``Model.m2m_field.clear()`` is exposed and does send m2m_changed; if
there are pre/post_delete handlers on the through model, they are
called as well after the m2m_changed.
If nothing else, this creates an additional discrepancy between
implicit and explicit through models. Switching from one to the other
requires porting all the related signal handlers (a non-trivial task
since m2m_changed has quite different API) and hope for the best. It
also makes things harder for library code that attempts to work on
arbitrary m2m fields, which normally wouldn't (or shouldn't) care
whether the through model is auto_created or not. Have these issues
been raised before ? If so, what's the suggested way to use signals
with m2m relations ?
George
--
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: m2m_changed signal
On Jun 14, 3:38 pm, Russell Keith-Magee
wrote:
> On Mon, Jun 14, 2010 at 9:18 PM, George Sakkis
> wrote:
> > I'm wondering what was the rationale for introducing a new separate
> > signal for m2m relationships, as opposed to using the existing ones on
> > the intermediate ('through') model.
>
> The normal model save/delete signals were disabled because of the
> potential for signal flood. If you add 100 objects to an m2m relation,
> you would have received 100 signals. This is a time consuming activity
> -- sending a signal consumes resources, even if it has no receivers;
> and as soon as you *do* connect a receiver, you consume even more
> resources. In the interests of performance, individual object signals
> on m2m operations are disabled in favor of the grouped m2m_changed
> signal.
I see, it makes sense for batch additions and removals.
> > * For m2m fields with auto_created intermediate model, calling
> > ``Model.m2m_field.add/remove/clear`` sends m2m_changed. However adding/
> > removing relations using directly the through model (e.g.
> > ``Model.m2m_field.through.objects.create(...)) does not send
> > m2m_changed. Adding handlers for pre/post_save, pre/post_delete on the
> > through model has no effect; the code specifically checks for
> > auto_created models and does *not* send these signals in this case.
>
> This sounds like an oversight to me.
>
> > * For m2m fields with a given intermediate model,
> > ``Model.m2m_field.add/remove`` are not exposed (at least for now but
> > this is under discussion) and therefore m2m_changed is not sent;
> > instead you have to handle addition/removal in pre/post_save, pre/
> > post_delete handlers on the through model. However
> > ``Model.m2m_field.clear()`` is exposed and does send m2m_changed; if
> > there are pre/post_delete handlers on the through model, they are
> > called as well after the m2m_changed.
> > If nothing else, this creates an additional discrepancy between
> > implicit and explicit through models. Switching from one to the other
> > requires porting all the related signal handlers (a non-trivial task
> > since m2m_changed has quite different API) and hope for the best. It
> > also makes things harder for library code that attempts to work on
> > arbitrary m2m fields, which normally wouldn't (or shouldn't) care
> > whether the through model is auto_created or not.
>
> Agreed, this certainly appears to be a inconsistency that needs to be
> cleaned up. Moving to a manually defined through model shouldn't
> require massive rewrites of signal handlers.
>
> > Have these issues
> > been raised before ? If so, what's the suggested way to use signals
> > with m2m relations ?
>
> No - these issues haven't been raised before (at least, not to my
> knowledge). If you could open tickets for these issues, I'd be much
> obliged. I'd be even more obliged if you'd try your hand at patches
> :-)
The first part was easy :-) http://code.djangoproject.com/ticket/13757.
As for a patch, I haven't thought of how a proper solution would look
like at this point; if you have any ideas feel free to post them here
or the ticket page.
George
--
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.
'exists' parameter for pre_save signal
Apologies if this has come up before, I didn't find anything related in the archives. As Model.save() is called both for inserts and updates, it would sometimes be useful for pre_save listeners to know whether the instance exists or not. This information is sent with post_save but by then it may be too late (e.g. under some conditions you may want to prevent an insertion from happening). In the current save_base() implementation, pre_save is sent before the instance's existence is determined, so I'm not sure if postponing it would break existing code. If there is no backwards compatibility issue, I can open a ticket and send a patch for it. George -- 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: 'exists' parameter for pre_save signal
On Jun 16, 4:51 am, Jeremy Dunck wrote: > On Tue, Jun 15, 2010 at 10:46 AM, George Sakkis > wrote: > > ...In the current save_base() > > implementation, pre_save is sent before the instance's existence is > > determined, so I'm not sure if postponing it would break existing > > code. If there is no backwards compatibility issue, I can open a > > ticket and send a patch for it. > > Well, a significant difference is that pre_save right now can cancel a > save before a query to determine existence is needed (0 vs 1 or 2 > queries). I'm not sure how many people really use pre_save's > cancellation feature, but I think we'd need some confidence that > moving wouldn't cause a problem for people counting on the 0-query > cancellation that's available right now. I see how this might be an issue for some, but my guess/belief is that often the existence or not of the instance is necessary to determine whether the save should be canceled. Besides, the incurred cost is at most one exists() query, which in 1.2 at least is quite lightweight. In any case, I opened a ticket and attached a patch (with updated tests) at http://code.djangoproject.com/ticket/13772. George -- 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: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?
On Jun 16, 4:22 pm, Peter Bengtsson wrote: > I have a modelform where I change the cleaned_data dict after I have > run is_valid() and I'm not sure if this is the totally wrong way of > doing things or if it's a bug. > My code broke when I upgraded to 1.2 so it did work back in the 1.1 > days. > > # models.py > class Person(models.Model): > name = models.CharField() > age = models.IntegerField() > ... > > # forms.py > class PersonForm(forms.ModelForm): > class Meta: > model = Person > > # views.py > > form = PersonForm(data=request.POST) > form.fields['age'].required = False > > if form.is_valid(): > if not form.cleaned_data['age']: > form.cleaned_data['age'] = > _fetch_age_by_name(form.cleaned_data['name']) > assert form.cleaned_data['age'] > person = form.save() # FAILS! Not sure why this fails but regardless, it's not good to have part of the validation logic outside the form. Instead define a clean() method in the form, move there the "if not ..." part and check if it also happens to solve the problem. By the way, the django-users group is more appropriate for questions about using Django, as opposed to developing Django itself. George -- 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: Make "required=True" on forms.fields.NullBooleanField do something useful?
On Jun 17, 11:39 am, Matt Hoskins wrote: > My use case is that I want to have a BooleanField on the model and on > the form want to have the choices of "Unknown", "Yes" and "No" in a > select list and give a "this field is required" error if the user > leaves it set to "Unknown" (i.e. require them to actively choose "Yes" > or "No", rather than defaulting to either of them). I thought I'd just > be able to use NullBooleanField with "required=True" set, but > NullBooleanField just ignores the "required" argument. To my mind it > would be a sensible use of "required" for NullBooleanField, but before > raising a ticket I thought I'd ask if it was a deliberate oversight or > if what I'm suggesting isn't sensible for some reason :). If you require a "Yes" or "No" choice, why do you use a NullBooleanField in the first place and not a BooleanField ? George -- 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: #6735 -- Class based generic views: call for comment
On Oct 1, 7:26 am, Russell Keith-Magee wrote: > > I've just added a summary of the last thread on class-based views [1]. Thanks for writing this up. Having missed the discussion on that thread, the summary saved me a whole lot of time. > I'd like to try and get this in for 1.3. It's a big feature, which > means it needs to be in by October 18. However, based on the state of > the patch that Ben has prepared, I think this is an achievable goal. > Lets be clear here - I don't particularly like *any* of the options on > the table so far. Before getting on topic, I'd like to note that these two paragraphs and the general lack of consensus make me a bit uneasy. I'd rather see the feature postponed to 1.4 or the October 18 date moved later than ending up with a poor solution. With the backwards compatibility policy being what it is, design mistakes become very costly. Having said that, I'm in favour of the first approach mentioned in the wiki (store state on request) and I'm surprised it doesn't seem to have any traction in this thread. The only argument against is "it's unusual to have a class where you can't store state on self" but even that can be overcome with an appropriate __setattr__/__getattr__ that access self.request.state under the hood. Unless someone tries self.__dict__[attr], it will look as if the state is stored on the view although it's actually stored in the request (or better request.state to avoid name clashes). Perhaps I am missing something but this seems to me foolproof and much cleaner than the alternatives. George -- 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: #6735 -- Class based generic views: call for comment
On Oct 2, 6:46 pm, Luke Plant wrote: > On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote: > > Having said that, I'm in favour of the first approach mentioned in the > > wiki (store state on request) and I'm surprised it doesn't seem to > > have any traction in this thread. The only argument against is "it's > > unusual to have a class where you can't store state on self" but even > > that can be overcome with an appropriate __setattr__/__getattr__ that > > access self.request.state under the hood. Unless someone tries > > self.__dict__[attr], it will look as if the state is stored on the > > view although it's actually stored in the request (or better > > request.state to avoid name clashes). Perhaps I am missing something > > but this seems to me foolproof and much cleaner than the alternatives. > > This breaks if you set any values in __init__ - since the request object > doesn't exist to store state on. Ah, good point. In any case, the argument against is reduced to "It's unusual to have a class where you can't store state on self while in the __init__". The __call__ and copy proposal has this limitation too, while being more error prone and less efficient overall. George -- 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: #6735 -- Class based generic views: call for comment
On Oct 3, 6:12 am, Ian Lewis wrote: > Other frameworks seem have View/Handler instances per request, such as > appengine's webapp so there is some precedent for creating an instance > per request. > > http://code.google.com/appengine/docs/python/gettingstarted/handlingf... > > Flask seems to do it the callable singleton way: > > http://flask.pocoo.org/docs/patterns/lazyloading/ > > Is there any precedent in other frameworks for doing it the singleton > way? Talking a bit about how other frameworks/libraries do this might > be a good idea to figure out what Joe User is likely to do. >From a brief look at Pylons, it also creates an instance per request: "These requests result in a new instance of the WSGIController being created, which is then called with the dict options from the Routes match." (http://pylonshq.com/docs/en/1.0/controllers/). No mentioning about setting state on self and no __init__ on controllers (even the base WSGIController doesn't define __init__). George -- 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: #6735 -- Class based generic views: call for comment
On Oct 3, 4:20 am, Russell Keith-Magee wrote: > On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote: > >> We could even wrap the "no args to __init__" error check in a method > >> that enables it to be overridden and silenced in a subclass; that way, > >> introducing the potentially un-threadsafe behavior would need to be an > > > Again, arguments to __init__ are not the issue. What would have to be > > checked is any assignment to self that takes place in __init__. How do > > you propose to check that? > > I don't. You've got me -- in my haste to propose an idea, I hadn't > considered assigning state in the constructor. FWIW with the proposal of overriding __setattr__ to do setattr(self.request.state, attr, value) you can check that; at __init__ there is no self.request yet. George -- 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: #6735 -- Class based generic views: call for comment
On Oct 4, 7:22 pm, Jacob Kaplan-Moss wrote:
> On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote:
> > Given that the primary complain against the __new__ solution is that
> > it's unintuitive to Python programmers that instantiating their class
> > results in some other class, why not simply go with a more explicit
> > classmethod. Simply used as:
>
> > url("^articles/$", ArticlesView.dispatch).
>
> Interesting. So `View.dispatch` would look something like:
>
> @classmethod
> def dispatch(cls, request, *args, **kwargs):
> instance = cls()
> callback = getattr(instance, request.method.lower())
> return callback(request, *args, **kwargs)
>
> (e.g. create an instance of `cls` then call `get`/`post`/etc. on it).
>
> Other than the slight cruftyness of `dispatch`, I quite like it. Seems
Since dispatch is going to be defined on the base View class, can't we
omit it from the urlconf and have the URLresolver do:
if isinstance(view, type) and issubclass(view, View):
view = view.dispatch
> it addresses most of the issues we've found so far. Doesn't solve the
> "pass configuration into __init__" idea, but frankly I didn't think
> much of that idea in the first place.
Luke's View.configure(**kwargs) classmethod takes care of that too.
George
--
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: #6735 -- Class based generic views: call for comment
On Oct 4, 9:16 pm, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > > Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor > arguments to it: > > url(r'^detail/author/(?P\d+)/$', > views.AuthorDetail.as_view(some_param=123), > name="author_detail"), > > It returns a newly created view function, which in turn calls your > class. > > http://bitbucket.org/spookylukey/django-class-views-experiments/src/t... It seems there is a corollary to D. Wheeler's quote: "all problems in computer science can be solved by another level of nested closures" ;-) > This was, in fact, suggested by Jari Pennanen in May :-( > > http://groups.google.com/group/django-developers/msg/997ac5d38a96a27b > > It's slightly less verbose for passing parameters, as you don't need a > separate 'configure' call. Indeed, although it's very slightly more verbose for the (common) case that you don't want to pass parameters: views.AuthorDetail.as_view(). Unless we "cheat" and have the resolver do: if isinstance(view, type) and issubclass(view, View): # or perhaps if it quacks like a View # if hasattr(view, 'as_view'): view = view.as_view() in which case it can be declared in the urlconf simply as views.AuthorDetail. George -- 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: #6735 -- Class based generic views: call for comment
On Oct 4, 10:55 pm, "David P. Novakovic"
wrote:
> On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote:
>
> > Since dispatch is going to be defined on the base View class, can't we
> > omit it from the urlconf and have the URLresolver do:
>
> > if isinstance(view, type) and issubclass(view, View):
> > view = view.dispatch
>
> Russ mentioned this one can't be decorated.
What does "this" refer to here ? It's just a shortcut for the common
case, you can always decorate the SomeClassView.dispatch:
url("^articles1/$", ArticlesView.dispatch), #
undecorated
url("^articles2/$", login_required(ArticlesView.dispatch)), #
decorated
url("^articles3/$", ArticlesView), # shortcut of the
first
# url("^articles4/$", login_required(ArticlesView)), # this doesn't
work
There is an asymmetry here but that's not to say it can't be
decorated, you just have to decorate the dispatch method instead of
the class view.
George
--
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.
OneToOneField clarifications
There are at least three open tickets related to OneToOneFields (#10227, #14043, #14368) that, even if deemed invalid, hint at lack of adequate documentation. After reading the docs on OneToOneField, I don't think one can easily answer the following questions: - It is mentioned that multi-table inheritance in implemented with an implicit O2O relation from the child to the parent model, but O2O is also useful for cases where neither model "extends" (in the OO sense) the other. What are the implications of model A linking to model B versus the inverse ? - Does A.save() propagate to the linked B instance (if any) or vice versa ? - Does A.delete() propagate to the linked B instance (if any) or vice versa ? - Is "A.link_to_B = B" equivalent to "B.link_to_A = A" ? - Is "A.link_to_B = None" or "B.link_to_A = None" valid ? - Are the assignments above done exclusively in memory or they may hit the database for reading and/or writing ? - How does null=True affect the answers to all the above ? Having clear answers to these would be a good first step to moving on with the mentioned tickets and perhaps augmenting the docs. George -- 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: OneToOneField clarifications
Thanks for the thorough reply, it was helpful, even without replying directly to any of the specific questions about the leakiness of the abstraction :-) I'll try to come up with patches+tests for #14043 and #14368 since they strike you as bugs. As for #10227, what do you think about my suggestion at the end for a new optional 'related_default' parameter ? To reiterate: - It's fully backwards compatible (if necessary); things can stay as they are by default. - Returning None is trivial by passing ``related_default=lambda instance: None``. - More flexible in cases where None is not ideal or suitable. - More appropriate than the suggested ``related_null`` parameter because "null" indicates a DB-level parameter (translating directly to NULL or NOT NULL db column). The related model of a O2O field does not even have such a column, so it doesn't make sense to say it is or is not null. George -- 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: OneToOneField clarifications
On Oct 8, 2:20 pm, Russell Keith-Magee wrote: > #14043 is clearly a bug to me (hence the accepted status). If I had to > guess at a cause, I'd say it's either: > * The OneToOneField special case not being handled by deletion traversal > * The related object cache on the o2o field not being cleared > correctly when null is assigned, causing the delete cascade to operate > on the older cached object. Turns out the related object didn't have a cache at all. The fix is a single line in SingleRelatedObjectDescriptor.__get__() that sets the back link from the related object, which ends up setting the cache [1]. > #14368 also strikes me as a bug, but it's one that's a little hard to > account for without some other changes. > > In saying bob.soul = None, you then need to save the soul object in > order for the change to take effect. That isn't something that is > currently done. However, interestingly, it *is* done if you do the > analogous operation with a foreign key -- if you assign a queryset to > a reverse FK relation, every object in the queryset is modified and > saved (and looking at the code, this is something we can *massively* > optimize with an update statement). In the interests of removing a > wierd inconsistency, I can cer > > However, this is a situation where pragmatism will need to beat > purity. OneToOne fields are also the cornerstone of inheritance, and > autosaving OneToOne reverse relations strikes me as something that > could backfire in the internals to inheritance. I'd need to see a > sample patch that doesn't break the existing test suite before I could > make any more firm judgements. Just posted a patch [2] that does the autosave and passes all the tests. In addition to the set to None issue, it also fixes the child reassignment problem. For the example above, doing ``bob.soul = other_soul`` currently raises a unique constraint integrity error when attempting to save() since bob would end up with two souls. With the patch, the existing bobs_soul is unlinked from bob and therefore no integrity error is raised. This is consistent with the FK behaviour. If for some reason you object to autosave for this case, it's straightforward to restrict it to only when setting to None. Since you mentioned the optimization of using an update statement instead of save(), the patch uses an update statement. I'm not sure if this is right though; shouldn't the pre_save/post_save signals be sent here (as well as in the FK case) ? George [1] http://code.djangoproject.com/attachment/ticket/14043/ticket-14043.patch [2] http://code.djangoproject.com/attachment/ticket/14368/ticket-14368.patch -- 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: OneToOneField clarifications
On Oct 9, 5:41 pm, Russell Keith-Magee wrote: > > I'll try to come up with patches+tests for #14043 and #14368 since > > they strike you as bugs. As for #10227, what do you think about my > > suggestion at the end for a new optional 'related_default' parameter ? > > I'm not sold on related_default. My problem with this is that it's not > just a callable that you need -- you need an object factory. We're > dealing with one-to-one relations, so we can't just point to a single > object, because a single object can only be used in one case. Tthere's > no way to guarantee that a query for existing unassigned objects will > return a result, so that means we need to be creating new objects. > Spontaneous object creation when someone requests an attribute sounds > like a recipe for disaster to me. And spontaneous related-object > creation as part of object creation sounds just as bad. I'm not sure I'm following. It's up to the user to pass whatever object factory is appropriate for the use case at hand, Django will not be creating objects automatically. I could pass ``related_default = lambda instance: MyModel.objects.get_or_create(fk=instance)`` so that at most one MyModel is created for any given instance, or ``related_default = lambda instance: MyModel(fk=instance)`` to return new unsaved instances that it's my responsibility to save later. And of course the most common case would be simply ``related_default = lambda instance: None`` where no object is created or retrieved. > I'm slightly less concerned about related_null; My hesitation here is > that while it's an elegant solution, I'm not sure whether we actually > have the problem that it is solving. > > *If* you accept that there is a reasonable use case for having both > "returns None" *and*' "raises exception" as responses for the reverse > lookup case, then I think it's a pretty good solution. > > I also like the fact that it is a completely backwards compatible > solution to the problem. From a purely pragmatic point of view, this > is a big plus. > > However, that all hinges on the "if". I'm not completely convinced > that base proposition holds. I can't think of an interpretation of the > reverse nullable O2O raising an exception that makes sense in an ORM > sense. I don't want to introduce a flag that provides two different > interpretations of behavior just because we can; there needs to be a > legitimate interpretation of that flag. I found convincing the comment posted by olau on 05/10/10, that basically there are four cases: (1) one to one # null=False, related_null=False (2) zero or one to one # null=True, related_null=False (3) one to zero or one # null=False, related_null=True (4) zero or one to zero or one # null=True, related_null=True The current behavior of reverse nullable O2O raising an exception corresponds to (2). For the Person/Soul example, a Soul may belong to one or zero Persons but a Person must have exactly one Soul, so Person().soul should raise a DoesNotExist. OTOH the Place/Shop example the relationship is probably (4); a Shop may or may not be located at a known Place and a Place may or may not be the location of a Shop, so DoesNotExist should not be raised. George -- 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: #6375 -- Class Based Views: Opinions on commit plan
On Oct 17, 5:58 pm, Russell Keith-Magee
wrote:
> On Sat, Oct 16, 2010 at 12:45 AM, Russell Keith-Magee
>
>
>
> wrote:
> > On Fri, Oct 15, 2010 at 1:09 AM, Justin Lilly
> > wrote:
> >> Because you asked, I think this sounds like a great idea.
>
> >> When you have decided you like the API for create/update
> >> views, please send another email to the list, so that we
> >> know we've hit a stable API to write documentation
> >> against.
>
> > I've finished my review of the create/update and date views. I've also
> > tweaked aspects of the base, detail and list views following feedback
> > and suggestions from IRC.
>
> > I've also added the placeholder skeleton of some documentation:
> > * a reference guide
> > * a topic guide, and
> > * a migration guide
>
> > So - review and document away :-)
>
> I've just finished writing the first draft of the reference
> documentation; and thanks to Andrew Godwin, we also have the bulk of
> some great topic documentation.
>
> Along the way, I've made some API tweaks as a result of some
> documentation-driven development. These tweaks are mostly internal
> structural things that won't have a huge effect unless you really get
> involved with the mixins.
>
> I should also be able to port the tutorial before I commit -- which,
> barring objection, I will do tomorrow night my time (about 24 hours
> from now). Speak now, etc etc.
It's not very important but it occured to me that we can solve the
second issue against the selected dispatch method ("If you do
AuthorDetail(foo=True).as_view(), instead of
AuthorDetail.as_view(foo=True), you will not get an exception, but
foo=True will effectively be ignored") by making "as_view" a
descriptor instead of a classmethod; see patch at http://gist.github.com/631306.
George
--
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.
#13772 design decision needed
This has been (rightly) marked as DDN, so I'm wondering if there are any thoughts on it to move it forward, one way or another. Original thread at http://groups.google.com/group/django-developers/browse_frm/thread/3b5939ba089bce51/67892d99a9a6aff3. George -- 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: #13772 design decision needed
On Oct 25, 4:28 pm, Russell Keith-Magee wrote: > On Sun, Oct 24, 2010 at 3:42 PM, Andrew Godwin wrote: > > On 23/10/10 12:54, George Sakkis wrote: > > >> This has been (rightly) marked as DDN, so I'm wondering if there are > >> any thoughts on it to move it forward, one way or another. Original > >> thread at > >>http://groups.google.com/group/django-developers/browse_frm/thread/3b > > >> George > > > My personal opinion on this is that we shouldn't put this into pre_save - > > I'd rather not have us doing a query before we get that far (and I've seen > > quite a few things that do some validation in pre_save, so cancellation > > happens reasonably often). > > > I'm also not particularly fond of adding yet another signal - we risk making > > it a mess of connection points, and signal calls, even if empty, do have > > overhead. > > > My preferred solution is either to not ship this, or replace it with a > > decorator which does this for you (so you can wrap your pre_save listener > > function in the decorator, which does the existence query for you, and which > > also passes this information back up to the model instance so we don't end > > up doing three queries). That way, people who want this can have it, we > > don't have a useless extra query in nearly any scenario, and we don't change > > current behaviour. > > For the record, I concur with Andrew's reasoning. Fair enough; unless someone objects in the next few days, I'll close it as wontfix. George -- 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: CUBRID as Django bakend
On Oct 30, 3:47 pm, Luke Plant wrote: > On Sat, 2010-10-30 at 05:59 -0700, Alex wrote: > > Hello, > > > Are there any plans to add CUBRID -http://www.cubrid.org/ad Django > > backend? > > > Seems to be very optimized DB for web application (opensource with > > internal support clastering, partitioning, efficient paging support) > > There are no plans I know of, and I for one have never heard of it until > now. That suggests it doesn't have a huge amount of market share, and > not enough to warrant a backend included in core as yet. I had not heard of it either; apparently they get that a lot [1]: """ Why very few global users know about CUBRID? All these years CUBRID has been available in Korea only, since it supported only Korean language. Therefore, most non-Korean developers and users from other countries have never heard of CUBRID. """ [1] http://www.cubrid.org/faq -- 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: OneToOneField clarifications
On Oct 9, 4:41 pm, Russell Keith-Magee wrote: > However, any of these plans hinge on us determining the right behavior > in the first place. Like I said last time -- I really need to hear > other opinions on this. Bumping this up (#10227). Btw the other two tickets (#14043, #14368) are RFC; would be great if some Django dev can verify and commit them. George -- 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: RFC: Add a "needinfo" state to triaging
On Nov 15, 6:31 am, Russell Keith-Magee wrote: > On Mon, Nov 15, 2010 at 1:00 PM, Tai Lee wrote: > > I like the idea of needmoreinfo as a resolution, which makes it clear > > to the reporter that they need to take the next step to re-open the > > ticket with more info. I don't think that closed with "invalid" and a > > comment makes this as clear. > > > However, I think there's another problem area where we need to be able > > to make it clear that someone needs to take the next step, and that is > > when a ticket has been "accepted", feedback has been given to the > > reporter, and the reporter has actioned that feedback (e.g. by > > uploading a patch with tests and docs as per the feedback). In this > > case the ticket will often languish in "accepted" for months (or > > years). Since it is frowned upon for a reporter to mark their own > > ticket as RFC, there's no way for the reporter to flag the ticket as > > feedback actioned and put it back in the court of the original triager > > or core developer who accepted it and gave their feedback, who can > > then either push it up to RFC or commit it themselves. > > Incorrect. There *is* a way for a reporter to flag that they have > followed through on feedback -- they update the 'need docs', 'needs > tests' and 'needs improvement' flags. > > Example workflow: > > * Alice creates a ticket, with an incomplete patch (no tests, > incorrect implementation) > * Bob reviews the patch, marks it "Accepted, needs tests, patch needs > improvement" > * Alice updates the patch, adding tests (but not changing the > implemenation). She removes the two flags. > * Charlie reviews the patch, resets the 'patch needs improvement flag' > * Alice updates the patch, fixing the implementation. She removes the > needs improvement flag. > * Daisy reviews the patch, marks it RFC. > > At any point in this process, a search for tickets "Accepted & has > patch & !needs improvement & !needs docs & !needs tests" will reveal > tickets that need review of some kind. These tickets either need to be > moved to RFC, or need to have their flags set to indicate the > deficiency in the patch. I admit I am guilty of breaking the (unknown to me) rule/etiquette of marking my own tickets RFC as a last resort to move them forward. Unlike your example workflow, my experience is often like this: * I create a ticket and submit a patch plus passing tests (no need for docs if it's a bug or a promise to add them once it is reviewed and accepted, i.e. it passes the DDN stage). * The ticket stays unreviewed for days, weeks or months or it is marked as accepted at best, without actual feedback how to proceed, one way or another. * At some point I mark it RFC since as far as I am concerned it *is* ready for checkin. * More time passes and still nobody bothers. If I'm doing it wrong, please educate me. George -- 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.
