[BUG #15978] subdomain caching - decision which idea is better

[Leszek Piątek]

There is a bug in django which leads to getting the same cache output
for different subdomains (but same PATH) - eg. pl.example.com/test/
and en.example.com/test/ . I've filled in BUG here:

http://code.djangoproject.com/ticket/15978

As aaugustin wrote, there are two ways of implementing:
- request.get_host():
  + simple, one line
  - we get different cache for www. and w/o www. prefix
- using sites framework:
  + more django way - we are using contrib!
  + one line
  + we don't need to install sites framework - fallback to
RequestSite: 
http://docs.djangoproject.com/en/dev/ref/contrib/sites/?from=olddocs#requestsite-objects

Next thing to consider if such modification doesn't introduce any
nasty side-effects?

PS: For now I'm closer to second solution, and according to
documentation something like:
Site.objects.get_current().domain
will always get the domain even when we do not have sites installed.

Second solution weren't tested by me it's purely theoretical. Waiting
for comments!

-- 
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: Class Based Views, can you not just pass the CBV instance to the template?

[Luke Plant]

On 09/05/11 16:22, fission6 wrote:
> Is there a way to re-factor the CBV approach so that templates simply
> get an instance of the CBV rather than trying to tweak context as well
> as having template context loaders like user and what not?
> 
> it seems there'd be a way in CBV to simple push the caller instance to
> the template where you'd have access to everything contained in the
> CBV instance (context, request, request->user, etc...)?
> 

I'm not convinced it's a great idea, but simply but 'self' in the
context dictionary.

This is django-users territory BTW.

Luke

-- 
OSBORN'S LAW
Variables won't, constants aren't.

Luke Plant || http://lukeplant.me.uk/

-- 
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: Re: get_or_create can still cause IntegrityError

[Cal Leeming [Simplicity Media Ltd]]

Hi guys,

I spent literally *months* trying to find the best way to resolve this
situation. On our high performance sites + backends (around 120qps, 50/50
split between read and write) we were getting IntegrityError raised by
get_or_create (which we now refer to as Object Collisions).

We are able to trigger the issue by having two scripts attempt to
get_or_create() a new object at the same time (it takes a few loop
iterations until it reproduces itself).

When get_or_create() is called, it'll raise a duplicate key exception, but
if you then attempt to do a .get() on the row using the same args/kwargs
straight away afterwards, you'll notice it returns an empty result. This (we
think) is because when you create a row within a transaction, although the
row isn't there, it will still raise a duplicate key error until the row is
either commited or rolled back.

Eventually, we created a modified get_or_create() which *reduce* the chance
of it happening:

http://pastebin.com/X1nvk0uq

However, we are still left with a final problem, which is we either put a
sleep() in the code (eww!) to increase the chance of a successful query, or
you raise an ObjectNotReady exception (custom), and then add logic into your
code to deal with this occurrence. The other option is that you re-factor
your code so that the time between commits on large chunks of code are as
small as possible, reducing the chance of this error. But, from what we can
tell, you can only "reduce" the chance of raising an ObjectNotReady, you
can't get rid of it entirely. (unless you get rid of transactions entirely
lol)


2011/5/8 Tomasz Zielinski 

> W dniu sobota, 7 maja 2011, 20:03:40 UTC+2 użytkownik David Cramer napisał:
>
>> Would it help (in PG-world) at least if the selects where in
>> savepoints as well?
>>
>
> In case you asked me - I don't know, I don't use PG on a daily basis...
>
>
> Anyway, let me list some possible solutions to launch the discussion:
> 1. Leave it as is, and update the documentation to warn users that
> get_or_create is problematic for concurrent writes unless used in READ
> COMMITED isolation level
> 2. Switch to my code and update the documentation to warn users
> that get_or_create commits the open transaction
> 3. Combine 1&2 and somehow allow two modes of operation for get_or_create,
> either based on a flag, or based on retrieved isolation level - or maybe add
> some get_or_create2 ?
> 4. Remove get_or_create, because it cannot be fixed to gracefully handle
> all common cases
>
> Re savepoint-based solution, I don't list it because I don't "feel" how it
> should work.
>
> Tomasz
>
> --
> 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.
>

-- 
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.

Field lookup types and backwards incompatibility

[Ulrich Petri]

Currently there are at least 4 open tickets [1-4] that propose the addition 
of new lookup types. Two of them [1,2] are in DDN because of backward 
compatibility concerns.
Following that (IMHO valid) logic makes it impossible to _ever_ add new 
lookup types to django without breaking backwards compatibility since field 
lookup types and field names share the same namespace.

Interestingly there has been one instance [5] where a lookup type was added 
after the 1.0 release (as far as I could gather from SVN). Why no backward 
comp. concerns were voiced in that case is not clear from the ticket.

Also there is currently no validation preventing field names from clashing 
with the already existing lookup types (date, year, month, day, etc. are 
IMHO "easy targets"). Whether that would be a desirable feature to have is 
also debatable since it would "artificially" limit a developers naming 
choices.
That using conflicting field names usually causes no problems but blows up 
with a rather confusing error message (e.g. "TypeError: Related Field has 
invalid lookup: [...]") when querying for that field through a relation 
without an explicit lookup isn't helpful either.

To solve this situation I think there are two possibilities:

   1. Make the current implementation "smarter": Don't automatically assume 
   that the last filter part is a lookup type but instead check first if there 
   is a field of that name.
   2. Separate the field name and lookup namespaces:
   Either change the separator for lookup types (e.g. to 3 underscores) or 
   introduce a completely different way of specifying lookups (e.g. 
   Thing.objects.filter(some_field__other_field=lookups.Contains("blah")))
   
Option one clearly is far less invasive (and possible to implement short 
term) but has the potential of user / developer confusion and maybe some 
hard-to-get-right edge cases.
Option two is a big hammer and possibly (probably?) not something the core 
devs are willing to change even in the long term?

So what do people think?

Bye Ulrich

[1] http://code.djangoproject.com/ticket/8424
[2] http://code.djangoproject.com/ticket/9596
[3] http://code.djangoproject.com/ticket/10911
[4] http://code.djangoproject.com/ticket/12489
[5] http://code.djangoproject.com/changeset/9818

-- 
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.

Class Based Views, can you not just pass the CBV instance to the template?

[fission6]

Is there a way to re-factor the CBV approach so that templates simply
get an instance of the CBV rather than trying to tweak context as well
as having template context loaders like user and what not?

it seems there'd be a way in CBV to simple push the caller instance to
the template where you'd have access to everything contained in the
CBV instance (context, request, request->user, etc...)?

-- 
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.

Bug in DateTimeInput: localization formatting decided during start-up?

[Jonathan Slenders]

Hi all,

This may be a bug in Django.

We have a lot of forms and datetimefields. Apparently, DateTimeInput
objects are initialized right after the first page load of the server,
where self.format for this instance is set according to the current
language.
DateTimeInput._format_value, which is called during rendering, will
see self.is_localized to be False, and render the data using the
language which happened to be used during the startup of the
application.

is_localized is passed from DateTimeField to Field to DateTimeInput.

For ModelForms, it's no option to pass localize=True for every input
element, and Field will always fallback to localize=False

In combination with localeurl, this bug causes unexpected behaviour,
all datetimefields will render dates according to the language of the
first request after the server has been started.


Feedback about how to work fix or work around this issue is welcome :)

Cheers,
Jonathan

I propose that Field.__init__ should have localize=None, and if no
localize parameter has been given, set self.localize according to
USE_L10N in the settings.

-- 
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.