Re: Proposal: Database Constraints

[Thejaswi Puthraya]

On Wednesday, April 2, 2014 4:09:37 AM UTC+5:30, simonb wrote:
>
> Hi
>
> Just FYI: back in 2007 GSOC there was a project to add constraints. The 
> syntax was as follows:
>

The code is at https://github.com/theju/django-check-constraints/
I doubt it works as is after the SQL compiler changes. It worked well on 
Postgres and SQLite. MySQL doesn't seem to support check constraints as of 
date.
 

>
> class Manufacturer(models.Model):
> mfg_name = models.CharField(maxlength=50)
>  car_sale_start = models.DateField()
> car_sale_end = models.DateField()
>  quantity_sold = models.IntegerField()
> car_price = models.IntegerField()
>
> class Meta:
> constraints = (
> ("check_name”, Check(mfg_name__like = 'Merc*')),
>  ("check_date”, Check(car_sale_start__between = [date(2007,1,1), 
> date(2008,1,1)])),
> ("check_end_date”, Check(car_sale_end__gte = 'car_sale_start')),
>  ("check_quantity”, Check(quantity_sold__gte = 0)),
> ("check_price”, Check(car_price__between = [0, 1])),
>   )
>
>
> So a list of constraint name and a Check() pairs. I think the idea was 
> that Check() could be ANDd or ORd together a bit like the Q() object.
>
> It worked with Postgres AFAIR.
>
> Simon
>
>
>
> On Tue, Apr 1, 2014 at 7:07 PM, schinckel 
> > wrote:
>
>> Some years ago, I discussed adding database-level check constraints into 
>> django: 
>> https://groups.google.com/forum/#!topic/django-developers/OJN5kpcseAg
>>
>> There is also an issue: https://code.djangoproject.com/ticket/11964
>>
>> I'm thinking about revisiting this, and wanted to get some discussion 
>> going about if this is a viable thing to do, and what it might look like.
>>
>>
>> Django already uses check constraints with PositiveIntegerField and 
>> friends, and at first blush I thought we might be able to co-opt some of 
>> that (indeed, I've got an internal monkey-patch that does, with some level 
>> of success). However, other than the fact there is already a 
>> 'sql_create_check' string, the actual python code that creates the check 
>> constraint probably isn't that usable in this context. Also, I like the 
>> idea of having more complex constraints (postgres has EXCLUDE constraints, 
>> but I don't know if there is an equivalent for other backends).
>>
>>
>> The approach that I am thinking of could see a syntax similar to:
>>
>>
>> class MyModel(models.Model):
>> start = models.DateField()
>> finish = models.DateField(constraints=[('check', '> start')])
>> user = models.ForeignKey('auth.User')
>>
>> This maps directly to creating a check constraint on the table:
>>
>>  ALTER TABLE "myapp_mymodel" ADD CONSTRAINT CHECK (finish > start)
>>
>> And, on the same model, a more complex constraint could look like:
>>
>>
>> class Meta:
>> constraints = [
>> ('exclude', [
>> ('overlaps', ['start','finish']),
>> ('equal', 'user')
>> ])
>>]
>>
>> I'm still unsure of the best way to describe this: it's supposed to mean:
>>
>>ALTER TABLE "myapp_mymodel" ADD EXCLUDE USING gist 
>> (daterange(start, finish) WITH &&, user_id WITH =)
>>
>> (but the python syntax is obviously immaterial at this stage).
>>
>>
>> Obviously, we can't just rely on the database to do the validation for 
>> us: it will just raise DatabaseErrors when something fails to validate 
>> anyway, so we would want to handle this stuff in django's validation 
>> framework.
>>
>> One possibility, at least with the field-based check constraint, would be 
>> to automatically add a field validator in the case of a CHECK constraint, 
>> however in the case of an EXCLUDE constraint, we can't really validate 
>> _without_ hitting the database. Does this mean we should treat EXCLUDE-type 
>> constraints as something that is beyond the scope of Django?
>>
>>
>>
>> With the new migrations framework, it's actually trivial to write a 
>> migration to add this type of constraint (or the check constraint), and a 
>> pre_save signal handler in conjunction with that would get 90% of the way, 
>> but it's still going to be open to a race condition anyway - the only way 
>> to actually do that is to try to save the object and see what the database 
>> says.
>>
>>
>> So, I guess I'm asking: is it worth pursuing this further, either in part 
>> or full?
>>
>> Matt.
>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/250ed272-198a-478f-b2ce-920afcf533a2%40googlegroups.com

Re: On django multi tenancy

[Riccardo Magliocchetti]

Hello,

Il 03/04/2014 00:15, Russell Keith-Magee ha scritto:


On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti
mailto:riccardo.magliocche...@gmail.com>> wrote:

Hi everyone,

i'd like to start a discussion about multi tenancy on this list.
I've been asked to move the discussion here by Aymeric in this ticket:

https://code.djangoproject.__com/ticket/17802


First we already have an initial patch sitting in this ticket:

https://code.djangoproject.__com/ticket/15089


patch here:


https://code.djangoproject.__com/attachment/ticket/15089/__15089-missing-site_id.diff



The patch basically change the SiteManager to return a Site based on
the request instead of the hardcoded settings.SITE_ID. Which while
useful for my usage is also making ticket 17802 obsolete since in
the mean time Sitemap has been switched to using get_current_site.

Another missing bit is having the request available everywhere, one
solution is to store in thread local storage that could be done
easily in a middleware without touching django core.


-1. Not. Going. To. Happen.

Search the archives of Django Developers if you want to know why. This
has been discussed to death.

Short version - it doesn't matter what pretty name you put on it, a
thread local is a global variable. We teach first year programmers not
to use globals, so why would we introduce them to Django as a core
framework idea?


I expected that :) i meant that if one wants that this can be done 
without touching django at all.



Another interesting thing (to me at least) would be being able to
use a different model for the Site so one can stores some site
specific configuration there (keeping in mind that in the patch
sites return but get_current_site are cached).

That could be obtained through this patch:

https://github.com/apollo13/__django/compare/ticket15089


or maybe like what is done for the custom User model.


What's the use case here? What additional data do you want to track?


For an ecommerce site "prices are without vat", "you need a vat id to 
register", something like that. Again this would nice but since one can 
use a separate model that's not a showstopper.




There's some more features for full multi tenancy listed here
https://code.djangoproject.__com/ticket/15089#comment:36


but the above will suffice for my usage so i will not dig into it.


Broadly speaking the approach you've described in #17802 makes sense to
me - that is, find somewhere where the request is needed, and make sure
it's available. I haven't dug in to the full consequences of introducing
the request where you've put it, but the broad strokes look right.


I was on the "add the request everywhere camp" until i've seen the 
15089-missing-site_id.diff patch. Lot of places have been converted to 
get_current_site so with the patch applied a site aware site would come 
for free. Let me mention that this does not change default behaviour.



Unfortunately, we're not going to rush into something here - once we add
or change an API, we need to support it, and we are committing to not
changing it - so before we make any changes, we need to make sure we're
not backing ourselves into a corner. That means solving the general
problem (or at least having an idea how we would address the general
problem), not just one small part of the problem.

The other approach that you haven't made mention of - Use a different
sites app altogether. Django's sites module isn't well designed for true
multi tenancy of the type that you're describing. However, it's also a
contrib app -- so it's entirely optional, and also replaceable. If you
have a specific set of requirements for multi tenancy, then write your
own third-party app to implement those changes, and use it.


It's entirely optional but lot of other contrib code knows about it 
(grep get_current_site). So using something else would be quite painful 
if you want to reuse other apps.



Also - Not Going to Happen. 1.7 beta has been released, so the window
for new features is closed. The best you can hope for at this point is
for inclusion in Django 1.8.


Yeah, thought about that after hitting enter :)

thanks,
riccardo

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://g

Re: Revisiting multiline tags

[Carl]

Hi Russell,

A brief example to answer your question...

On Monday, 19 August 2013 00:59:13 UTC+1, Russell Keith-Magee wrote:
>
>  
>
>> I wondered if you are using internationalisation? If so have you run into 
>> the same problems or is it easy to circumvent for you?
>>
>  
> I'm not using it myself, so can you clarify how multiline tags affects 
> internationalization?
>

Consider a basic case:
{% blocktrans with adjective=widsom.adjective animal=wisdom.animal %}The {{ 
adjective }} {{animal}} jumps over the lazy dog, lorem ipsum dolor sit 
amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
labore et dolore magna aliqua."{% endblocktrans %}

*(NB it causes a great deal of pain to have line breaks inside {% 
blocktrans %}; advice originally from Jacob Burch's "Gringo's Guide to 
Internationalisation 
" at 
DC 2012)*

If nothing else, multi-line template tags would allow the following (with 
variables on their own line) instead:
{% blocktrans with adjective=widsom.adjective animal=wisdom.animal 
%}The {{ adjective }} {{animal}} jumps over the lazy dog, lorem ipsum dolor 
sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
labore et dolore magna aliqua."{% endblocktrans %}
which I am by now willing to give my right arm for after two projects spent 
hunting for text in lines that span more than 1920px at 14pt.

I'm not thrilled by how this ends up looking, but surely "usable i18n" is 
at least as high a priority as "stylistic preference".

The really obvious use case for me is {% url %} — here is a verbatim line 
from a current project:
{% url 'workshop_manuscript_detail' workshop_slug=workshop.slug 
slug=manuscript.slug as url %}

I'm as much of an opinionated aesthete as the next person, but do people 
honestly prefer that over the alternative?
{% url 'workshop_manuscript_detail' 
workshop_slug=workshop.slug 
slug=manuscript.slug as url %}

As someone said earlier in the thread, making Python programmers deal with 
long lines seems like some special form of torture ;)

Cheers,

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d5476fc3-5d1b-49ef-8be9-f401b0410f7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Daniele Procida]

On Thu, Apr 3, 2014, Carl  wrote:

>As someone said earlier in the thread, making Python programmers deal with 
>long lines seems like some special form of torture ;)

My own use case is this:

{% with placeholder_width=960 generic_main_width=523 
sidebar_image_size="294x196" entity_image_size="445x384" 
entity_map_size="445x100" person_map_size="445x100" sidebar_map_size="296x100" 
person_image_size="460x460" person_thumbnail_size="40x40" 
lightbox_max_dimension=600 plugin_thumbnail_size="75x75" 
place_image_size="627x418" place_map_size="294x182" body_heading_level=2 %}

Now that's very horrible to read.

This would be much nicer:

{% with 
placeholder_width=960 
generic_main_width=523 
sidebar_image_size="294x196" 
entity_image_size="445x384" 
entity_map_size="445x100" 
person_map_size="445x100" 
sidebar_map_size="296x100" 
person_image_size="460x460" 
person_thumbnail_size="40x40" 
lightbox_max_dimension=600 
plugin_thumbnail_size="75x75" 
place_image_size="627x418" 
place_map_size="294x182" 
body_heading_level=2 
%}

And yes, there is a good reason for wanting to use {% with %} in this way!

Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[dude]

Very good idea i think!

Many people love format source codes to be beauty. But they can’t because 
django templates does’t support multiline tags.


03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):

> On Thu, Apr 3, 2014, Carl  wrote:
> 
>> As someone said earlier in the thread, making Python programmers deal with 
>> long lines seems like some special form of torture ;)
> 
> My own use case is this:
> 
> {% with placeholder_width=960 generic_main_width=523 
> sidebar_image_size="294x196" entity_image_size="445x384" 
> entity_map_size="445x100" person_map_size="445x100" 
> sidebar_map_size="296x100" person_image_size="460x460" 
> person_thumbnail_size="40x40" lightbox_max_dimension=600 
> plugin_thumbnail_size="75x75" place_image_size="627x418" 
> place_map_size="294x182" body_heading_level=2 %}
> 
> Now that's very horrible to read.
> 
> This would be much nicer:
> 
> {% with 
>placeholder_width=960 
>generic_main_width=523 
>sidebar_image_size="294x196" 
>entity_image_size="445x384" 
>entity_map_size="445x100" 
>person_map_size="445x100" 
>sidebar_map_size="296x100" 
>person_image_size="460x460" 
>person_thumbnail_size="40x40" 
>lightbox_max_dimension=600 
>plugin_thumbnail_size="75x75" 
>place_image_size="627x418" 
>place_map_size="294x182" 
>body_heading_level=2 
> %}
> 
> And yes, there is a good reason for wanting to use {% with %} in this way!
> 
> Daniele
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> For more options, visit https://groups.google.com/d/optout.



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisiting multiline tags

[Daniel Ellis]

Hmm, that does seem like a great idea!


On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:

> Very good idea i think!
>
> Many people love format source codes to be beauty. But they can’t because
> django templates does’t support multiline tags.
>
>
> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>
> > On Thu, Apr 3, 2014, Carl  wrote:
> >
> >> As someone said earlier in the thread, making Python programmers deal
> with
> >> long lines seems like some special form of torture ;)
> >
> > My own use case is this:
> >
> > {% with placeholder_width=960 generic_main_width=523
> sidebar_image_size="294x196" entity_image_size="445x384"
> entity_map_size="445x100" person_map_size="445x100"
> sidebar_map_size="296x100" person_image_size="460x460"
> person_thumbnail_size="40x40" lightbox_max_dimension=600
> plugin_thumbnail_size="75x75" place_image_size="627x418"
> place_map_size="294x182" body_heading_level=2 %}
> >
> > Now that's very horrible to read.
> >
> > This would be much nicer:
> >
> > {% with
> >placeholder_width=960
> >generic_main_width=523
> >sidebar_image_size="294x196"
> >entity_image_size="445x384"
> >entity_map_size="445x100"
> >person_map_size="445x100"
> >sidebar_map_size="296x100"
> >person_image_size="460x460"
> >person_thumbnail_size="40x40"
> >lightbox_max_dimension=600
> >plugin_thumbnail_size="75x75"
> >place_image_size="627x418"
> >place_map_size="294x182"
> >body_heading_level=2
> > %}
> >
> > And yes, there is a good reason for wanting to use {% with %} in this
> way!
> >
> > Daniele
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[dude]

More useful example is not ‘very long with’, just a situation with html code 
block, which have in left sir already offset about 60 cols. And when we add 
there any django template tag with params it goes exceed 80 lines (for 
standard). But we can use 120 of course. In real life html tree can be very 
deep. Html tags can be multilines and this is awesome when you want make deep 
tree good looking, but dj templates  not support it.

If django can support multiline it would be great i think and community will 
like this feature immediately.

03 апр. 2014 г., в 21:29, Daniel Ellis  написал(а):

> Hmm, that does seem like a great idea!
> 
> 
> On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:
> Very good idea i think!
> 
> Many people love format source codes to be beauty. But they can’t because 
> django templates does’t support multiline tags.
> 
> 
> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
> 
> > On Thu, Apr 3, 2014, Carl  wrote:
> >
> >> As someone said earlier in the thread, making Python programmers deal with
> >> long lines seems like some special form of torture ;)
> >
> > My own use case is this:
> >
> > {% with placeholder_width=960 generic_main_width=523 
> > sidebar_image_size="294x196" entity_image_size="445x384" 
> > entity_map_size="445x100" person_map_size="445x100" 
> > sidebar_map_size="296x100" person_image_size="460x460" 
> > person_thumbnail_size="40x40" lightbox_max_dimension=600 
> > plugin_thumbnail_size="75x75" place_image_size="627x418" 
> > place_map_size="294x182" body_heading_level=2 %}
> >
> > Now that's very horrible to read.
> >
> > This would be much nicer:
> >
> > {% with
> >placeholder_width=960
> >generic_main_width=523
> >sidebar_image_size="294x196"
> >entity_image_size="445x384"
> >entity_map_size="445x100"
> >person_map_size="445x100"
> >sidebar_map_size="296x100"
> >person_image_size="460x460"
> >person_thumbnail_size="40x40"
> >lightbox_max_dimension=600
> >plugin_thumbnail_size="75x75"
> >place_image_size="627x418"
> >place_map_size="294x182"
> >body_heading_level=2
> > %}
> >
> > And yes, there is a good reason for wanting to use {% with %} in this way!
> >
> > Daniele
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> > For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



smime.p7s
Description: S/MIME cryptographic signature

Re: On django multi tenancy

[Riccardo Magliocchetti]

Hello,

Il 03/04/2014 09:46, Riccardo Magliocchetti ha scritto:

Hello,

Il 03/04/2014 00:15, Russell Keith-Magee ha scritto:


On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti
mailto:riccardo.magliocche...@gmail.com>> wrote:

First we already have an initial patch sitting in this ticket:

https://code.djangoproject.__com/ticket/15089


patch here:


https://code.djangoproject.__com/attachment/ticket/15089/__15089-missing-site_id.diff


I updated the patch to work againt latest git master, test passes [1] 
and doc builds fine.


https://code.djangoproject.com/attachment/ticket/15089/0001-By-using-the-request-to-do-the-Site-matching.patch

thanks,
riccardo

[1] Actually i have this "ERROR: test_righthand_power 
(expressions_regress.tests.ExpressionOperatorTests)"
there with "IntegrityError: NOT NULL constraint failed: 
expressions_regress_number.the_integer"  but it's completely unrelated 
to sites framework, traceback here http://pastebin.com/MSmu8mi9


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/533DA7A0.1040802%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

Have any of you tested my code which gives you multi-line tags?

I'd be interested in hearing how it fares "in the real world"

--
C



On 4 April 2014 01:52, dude  wrote:

> More useful example is not ‘very long with’, just a situation with html
> code block, which have in left sir already offset about 60 cols. And when
> we add there any django template tag with params it goes exceed 80 lines
> (for standard). But we can use 120 of course. In real life html tree can be
> very deep. Html tags can be multilines and this is awesome when you want
> make deep tree good looking, but dj templates  not support it.
>
> If django can support multiline it would be great i think and community
> will like this feature immediately.
>
> 03 апр. 2014 г., в 21:29, Daniel Ellis  написал(а):
>
> Hmm, that does seem like a great idea!
>
>
> On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:
>
>> Very good idea i think!
>>
>> Many people love format source codes to be beauty. But they can’t because
>> django templates does’t support multiline tags.
>>
>>
>> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>>
>> > On Thu, Apr 3, 2014, Carl  wrote:
>> >
>> >> As someone said earlier in the thread, making Python programmers deal
>> with
>> >> long lines seems like some special form of torture ;)
>> >
>> > My own use case is this:
>> >
>> > {% with placeholder_width=960 generic_main_width=523
>> sidebar_image_size="294x196" entity_image_size="445x384"
>> entity_map_size="445x100" person_map_size="445x100"
>> sidebar_map_size="296x100" person_image_size="460x460"
>> person_thumbnail_size="40x40" lightbox_max_dimension=600
>> plugin_thumbnail_size="75x75" place_image_size="627x418"
>> place_map_size="294x182" body_heading_level=2 %}
>> >
>> > Now that's very horrible to read.
>> >
>> > This would be much nicer:
>> >
>> > {% with
>> >placeholder_width=960
>> >generic_main_width=523
>> >sidebar_image_size="294x196"
>> >entity_image_size="445x384"
>> >entity_map_size="445x100"
>> >person_map_size="445x100"
>> >sidebar_map_size="296x100"
>> >person_image_size="460x460"
>> >person_thumbnail_size="40x40"
>> >lightbox_max_dimension=600
>> >plugin_thumbnail_size="75x75"
>> >place_image_size="627x418"
>> >place_map_size="294x182"
>> >body_heading_level=2
>> > %}
>> >
>> > And yes, there is a good reason for wanting to use {% with %} in this
>> way!
>> >
>> > Daniele
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Django developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-developers+unsubscr...@googlegroups.com.
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > Visit this group at http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCpn00fDjEJmrs%3DwK8Kx8q4EG0jj8R0ma246n746Pi1Fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

[Yo-Yo Ma]

It's so easy to build an Account or Tenant or Site model of your own, do a 
little leg work, and you've got a multitenant app with all the custom 
functionality you need. Getting caught up in trying to use contrib apps and 
hacking things together turned out to be more work once you pass the basics.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ee498b83-536a-48f2-8173-c17fdd657162%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.