Anonymous session carries over to authenticated session
Posted original on the Django Users group because I thought I was missing something: http://groups.google.com/group/django-users/browse_thread/thread/a612987d2c3487e4 Per what Tom mentions on the Django Users thread: - an authenticated user logging in under a different account keeps the session key, but session data is flushed - a non-authenticated user keeps the session data but gets a new session key This behavior is confusing especially the latter since data was persisted pre-auth to post-auth even though the session key changed. There is certainly utility for persisting post-auth (e.g. e-commerce), but this is not documented anywhere. How would everyone feel about making this a setting, e.g. SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now otherwise it would flush the non-auth session. -- 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.
Re: Anonymous session carries over to authenticated session
Here is the relevant code: https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L63-70 On Nov 15, 1:44 pm, Byron Ruth wrote: > Posted original on the Django Users group because I thought I was > missing > something:http://groups.google.com/group/django-users/browse_thread/thread/a612... > > Per what Tom mentions on the Django Users thread: > > - an authenticated user logging in under a different account keeps the > session key, but session data is flushed > - a non-authenticated user keeps the session data but gets a new > session key > > This behavior is confusing especially the latter since data was > persisted pre-auth to post-auth even though the session key changed. > There is certainly utility for persisting post-auth (e.g. e-commerce), > but this is not documented anywhere. > > How would everyone feel about making this a setting, e.g. > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > otherwise it would flush the non-auth session. -- 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.
Re: Anonymous session carries over to authenticated session
Indeed, all of the settings are slowly becoming unwieldy. I will write my own `login()` function in the meantime, but the docs should definitely be update to note this behavior. On Nov 15, 2:27 pm, ptone wrote: > On Nov 15, 10:44 am, Byron Ruth wrote: > > > > > How would everyone feel about making this a setting, e.g. > > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > > otherwise it would flush the non-auth session. > > I do think the current behavior is worth a note in the docs - like you > say - there are reasons to not flush it. > > but this doesn't seem to merit a setting in the face of the ever > growing problem of settings bloat. > > Ifhttps://code.djangoproject.com/ticket/17209comes to pass, this > could be something on a login class, but otherwise I think you are > better off just doing a custom login view if you want to flush the > session. > > -Preston -- 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.
Re: Anonymous session carries over to authenticated session
Ticket opened for documentation: https://code.djangoproject.com/ticket/17236 On Nov 15, 3:35 pm, Byron Ruth wrote: > Indeed, all of the settings are slowly becoming unwieldy. I will write > my own `login()` function in the meantime, but the docs should > definitely be update to note this behavior. > > On Nov 15, 2:27 pm, ptone wrote: > > > > > > > > > On Nov 15, 10:44 am, Byron Ruth wrote: > > > > How would everyone feel about making this a setting, e.g. > > > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > > > otherwise it would flush the non-auth session. > > > I do think the current behavior is worth a note in the docs - like you > > say - there are reasons to not flush it. > > > but this doesn't seem to merit a setting in the face of the ever > > growing problem of settings bloat. > > > Ifhttps://code.djangoproject.com/ticket/17209comesto pass, this > > could be something on a login class, but otherwise I think you are > > better off just doing a custom login view if you want to flush the > > session. > > > -Preston -- 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.
Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`
My use case is for regenerating aggregate data cache at a table level. Simply calling a single signal after a bulk operation is complete would enable invalidating such aggregate cache. There is not a very clean alternate solution to this problem unless using database triggers which calls an external script that invalidates the cache. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/DAaTRIau8h8J. 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.
Re: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`
Sure I guess you _could_ take a generic signals approach to handling all modify operations, but for each operation context is important. The state of the object(s) matters when performing operations. The `pre_save` and `post_save` signals for example have a `created` flag which allows for filtering out the new objects versus existing ones. Likewise, having a distinct pair of delete signals ensures you don't make the mistake of performing operations on objects that are now deleted. Ultimately my request is for batch or bulk-level signals. Up until recently, the lack of API for bulk operations in the ORM has been a non-starter for doing any kind of ETL for large amounts of data (not that I ever expected Django to have suitable APIs or performance for ETL pipelines). But now using it's at least reasonable to argue to include in a pipeline if there would be a suitable set of bulk-level signals when doing batch inserts, updates and deletes. On Sunday, March 25, 2012 6:23:46 PM UTC-4, Anssi Kääriäinen wrote: > > A somewhat different proposal is in ticket #17824: Add generic > pre/post_modify signal. I think the generic > "object modified" signals would fit your use case very well. > > The idea is that there would be just one signal which would be fired for > any data modifying ORM operation. > The arguments for it: > - fired for every operation modifying data > - one signal to listen to for all data modifications > The likely counter-arguments: > - duplicates the existing signals > - the callbacks end up being a big "switch statement", and thus you end > up separating save, delete etc > anyways. > - the API isn't good enough > > From performance perspective there should be no big problems: the signal > is given an iterable as > "objs_modified" argument. For .update() for example, where you don't want > to fetch all the objects for > performance reasons, you could just pass qs.filter(update_filters) as the > modified objects. This way > there would be no performance penalty, except if there is actual use of > the signal. > > I would like to see a generic pre/post modify signal, as I think it is > much easier to use than using > the pre/post save/delete + m2m_changed signals. However, I do not feel > strongly at all about this, just > something I would find useful. I believe having total control of all data > modifying operations using Django > signals would be a welcome addition for many users. > > - Anssi > ____ > From: django-developers@googlegroups.com[ > django-developers@googlegroups.com ] > On Behalf Of Byron Ruth [bjr...@gmail.com] > Sent: Sunday, March 25, 2012 17:46 > To: django-developers@googlegroups.com > Subject: Add signals for QuerySet bulk operations such as `delete`, > `update, `bulk_create` > > My use case is for regenerating aggregate data cache at a table level. > Simply calling a single signal after a bulk operation is complete would > enable invalidating such aggregate cache. There is not a very clean > alternate solution to this problem unless using database triggers which > calls an external script that invalidates the cache. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/DAaTRIau8h8J<https://groups.google.com/d/msg/django-developers/-/DAaTRIau8h8J> > . > To post to this group, send email to > django-developers@googlegroups.com > . > To unsubscribe from this group, send email to > django-developers+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en<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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/RCufSikz0cEJ. 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.
Re: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`
I guess this would not be too different from how the `m2m_changed` signal works. The arguments would (at a bare minimum) include the `sender`, `action`, and `using`, then depending on the `action` other arguments may be passed in. I would imagine if this approach would be taken, migrating existing signals over would follow the normal deprecation policy. But it could be introduced for the bulk-level operations initially without breaking any compatibility. On Monday, March 26, 2012 4:00:14 AM UTC-4, Anssi Kääriäinen wrote: > > On 03/26/2012 06:34 AM, Byron Ruth wrote: > > Sure I guess you _could_ take a generic signals approach to handling > > all modify operations, but for each operation context is important. > > The state of the object(s) matters when performing operations. The > > `pre_save` and `post_save` signals for example have a `created` flag > > which allows for filtering out the new objects versus existing ones. > > Likewise, having a distinct pair of delete signals ensures you don't > > make the mistake of performing operations on objects that are now > deleted. > > The pre/post_modify signal would have the context available. (parameters > action='save/delete/bulk_create/update' and action_args). It would be > kind of all the current signals compressed into one. If that is a good > design or not is a good question. I think it would be useful, but I > would not be surprised if other core developers have different opinion > of such a signal. > > The reason the generic signal would be useful is that more often than > not you are interested in _all_ the data modifying operations done to a > model, not just in the save or delete or update subset. Hence, one mount > point for all the operations. What is done in the signal could be very > different for the .update() case than for the .save() case, but on the > other hand there are cases where the generic signal handler would reduce > the amount of work. For search engine reindexing (Haystack for example), > you would just do reindex(modified_objects) for all cases except delete. > Similar for cache invalidation. So, such a signal could simplify some > common operations. > > Having signals for all data modifying operations is in my opinion > important. It is of course possible to achieve this without generic > signals by just adding pre/post update / bulk_create signals. The > bulk_create signal is problematic because you do not have the auto-pk > values available even in post_bulk_create signal. For PostgreSQL and > Oracle having the PKs would be possible using the "RETURNING ID" syntax. > SQLite could be hacked to support returning the IDs (there are no > concurrent transactions, hence you know what the IDs will be, or at > least I think this is the case). But for MySQL I do not know of any way > of returning the IDs. Except for locking the table for the duration of > the insert... > > - Anssi > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/16BAPV5h3FsJ. 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.
Form.set_data method
Here is the ticket: https://code.djangoproject.com/ticket/19668 and the pull request https://github.com/django/django/pull/674 One user commented on the ticket raising a concern that it could possibly be misused if the data is set after it had been used. It is certainly a valid concern, however it should be made clear in the docs when to use it and/or raise an exception if `is_valid` has already been called. Thoughts? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Form.set_data method
I don't understand your argument regarding overriding `__init__`. Nothing has changed in __init__, the logic for setting `data` and `files` is simply moved to a method. You _can_ still pass `request.POST` and `request.FILES` into the constructor. If a user extends __init__ (I do it all the time), you still need (are expected) to call `super` to _finish_ initialization. On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote: > > On Thursday 31 January 2013, Byron Ruth wrote: > > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the > > pull request https://github.com/django/django/pull/674 > > > > One user commented on the ticket raising a concern that it could > possibly > > be misused if the data is set after it had been used. It is certainly a > > valid concern, however it should be made clear in the docs when to use > it > > and/or raise an exception if `is_valid` has already been called. > > > > Thoughts? > > While this is backwards-compatible per se, using it in views is generally > not > backwards-compatible with user form classes (you can't tell what they do > in > their initializers); thus, generic views (and also some not-generic views) > are > forced to keep using the "old way" unless the (user) form code is altered. > Which means, you'll have two ways to do the same thing (in views), without > a > clear preference between them. > > So if you want this judged as a backwards-compatible change, I'm -1. > > As a non-backwards-compatible change, I'd like it, but I don't think it's > worth the disruption, so I'm -0. > > Either way, I'm not a core dev. > > Shai. > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Form.set_data method
I don't want to belabor our difference in understanding/opinion, but there are two ways to extend __init__. Processing before super is called, and processing after super is called: # Common pre-processing.. class MyForm(forms.Form): def __init__(self, request, *args, **kwargs): # Use downstream somewhere.. self.request = request super(MyForm, self).__init__(*args, **kwargs) # Common post-processing.. class MyForm(forms.Form): def __init__(self, *args, **kwargs): super(MyForm, self).__init__(*args, **kwargs) # tweak various field properties.. In either case, the `data` and `files` attributes are set as they were before which means they are still available just like before. Am I missing something? Do you or Shai have a real example that would correct understanding? On Jan 31, 2013, at 11:56 AM, Alex Ogier wrote: > Byron, I think Shai is suggesting that a user's form class may do extra > processing in __init__ on the data and files fields. If someone starts using > the new pattern in their views, it will break those classes because they > expect the initializer to be called with valid data when there is any. Your > new method will bypass their customizations. > > Best, > Alex Ogier > > > On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth wrote: > I don't understand your argument regarding overriding `__init__`. Nothing has > changed in __init__, the logic for setting `data` and `files` is simply moved > to a method. You _can_ still pass `request.POST` and `request.FILES` into the > constructor. If a user extends __init__ (I do it all the time), you still > need (are expected) to call `super` to _finish_ initialization. > > > On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote: > On Thursday 31 January 2013, Byron Ruth wrote: > > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the > > pull request https://github.com/django/django/pull/674 > > > > One user commented on the ticket raising a concern that it could possibly > > be misused if the data is set after it had been used. It is certainly a > > valid concern, however it should be made clear in the docs when to use it > > and/or raise an exception if `is_valid` has already been called. > > > > Thoughts? > > While this is backwards-compatible per se, using it in views is generally not > backwards-compatible with user form classes (you can't tell what they do in > their initializers); thus, generic views (and also some not-generic views) > are > forced to keep using the "old way" unless the (user) form code is altered. > Which means, you'll have two ways to do the same thing (in views), without a > clear preference between them. > > So if you want this judged as a backwards-compatible change, I'm -1. > > As a non-backwards-compatible change, I'd like it, but I don't think it's > worth the disruption, so I'm -0. > > Either way, I'm not a core dev. > > Shai. > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
SQL join promotion as a result of querying for a NULL value
I am speaking of this particular if statement: http://code.djangoproject.com/browser/django/tags/releases/1.2.4/django/db/models/sql/query.py#L1051 There are a few implications of this assumption. One being, that if the user is actually trying to get the "real" rows that exist with a column that has a NULL value, they will get those in addition to all the rows generated that are empty as a result of the LEFT OUTER JOIN. Given the example: SELECT * FROM table1 INNER JOIN table2 ON (table2.table1_id = table1.id) WHERE table2.foo IS NULL With the INNER JOIN, if table2 is empty, no rows will return. Any table2 rows that match 'foo IS NULL' will return if and only if it references a row in table1 (obviously if table1_id is not nullable, this will always be true). SELECT * FROM table1 LEFT OUTER JOIN table2 ON (table2.table1_id = table1.id) WHERE table2.foo IS NULL With the LEFT OUTER JOIN, if table2 is empty, all of the rows from table1 will return! In addition, any rows in table2 that match 'foo IS NULL' will return as well as the ones that don't have rows that exist in the table! This seems like very strange behavior to have by default. I suggest there be a way to prevent the joins from being promoted to LEFT OUTER JOIN when the specifying a QuerySet condition using NULL values. Obviously the fact that people have been relying on this behavior for 2+ years either proves to be the correct assumption or not many have come across these scenarios. I propose exposing a small API that allows for keeping INNER JOINs and not promoting simply because of a NULL value. Any thoughts or feedback on this argument? -- 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: SQL join promotion as a result of querying for a NULL value
> Just to be clear: The assumption is that if: > 1) the user filtered on a related model's field > 2) with is_null=True, and > 3) there is a nullable FK in the chain leading to the filtered field > (this is checked by promote_alias_chain), > then: > use a left outer join. Indeed. > Not at all (given the full set of assumptions as I've described). How else > would you express your will to have a left join? I have used Django for quite a while now and clearly I have never run into this before, so I agree that it isn't a _bad_ default, but rather it somewhat surprised me when I found out the behavior. I also am not arguing that the assumptions are wrong, but rather there are implications that are not obvious (until you run into it). > Really, it's mostly a case where the Django ORM query language is not as > expressive as SQL; I think the choice made by Django here is for the more > common case. Absolutely. > You can limit the rows to "real" rows by adding a condition such as > related__pk__isnull=False. With current code, as far as I understand it, this > will still do a left join, but pick from it only "real" rows; the question > then becomes one of performance, not correctness. > This also validates the decision to do a left join when in doubt: From there, > you can restore inner-join semantics. You can't go the other way around. Yep, that is the solution I have fallen back to in the meantime. > I think a better, more general approach would be to allow explicit setting of > join methods: > > qs.join_methods(rel1=Inner, rel2__rel2A=Left) I honestly wouldn't mind if it wasn't even public API (as with the QuerySet), my use case is non-traditional and in many cases I am using the internal queryset.query API for some of my joins. It currently is more of issue that the logic is deep and non-configurable. Possibly a flag that gets propagated down to query.add_filter() to prevent promotion to LOJ. -- 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.
