Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner:  kmpm   

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by oldium):

 Replying to [comment:43 hejsan]:
 > Replying to [comment:42 oldium]:
 > > The db_schema is already implemented in attached patches. There is no
 magic included, you just define a variable APP_SCHEMA (or any other name)
 at the top of the file and use it later on.
 > Ok, great. Should I apply all the attached patches in order or just the
 last one?

 You need the last two patches - generic-db_schema-r11231.diff and generic-
 db_schema-update.patch.

 > What do you think about the USE_APP_NAMES_AS_SCHEMA_NAMES idea? Is it
 doable?

 I don't know about new features mentioned by kmpm, I'm currently busy with
 other things (non-Django). You are free to dive deeper into it :-)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12337: save_m2m() does not honor save_instance's exclude argument

[Django]

#12337: save_m2m() does not honor save_instance's exclude argument
+---
 Reporter:  margieroginski  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Uncategorized   | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 save_m2m() does not seem to honor the exclude argument that is passed in
 to save_instance.  I have a form that includes a particular m2m field,
 however I am trying to avoid saving that field.  To do this I am setting
 self._meta.exclude explicitly, just prior to calling the form's save
 method. After saving the task, I do the standard save_m2m() to save the
 m2m fields.  I find that non-m2m fields are correctly excluded from the
 save if specified in this way via self._meta.exclude, but that m2m fields
 are not excluded from the save if specified this way.  This seems
 inconsistent.

 I suppose it could be rejected as a bug based on the fact that exclude is
 a model meta attribute, and if used exactly as specified in the doc, I
 wouldn't have the field in my form at all, so this wouldn't come up.

 Here is some background on what I am doing to make a case for fixing this.
 I have an app sort of like the admin app.  Say I have a model called
 'foo'.  User A views it and user B views it.  User A then changes field
 'status', and saves it.  User B then changes field 'priority' and saves
 it.  I need to avoid having user B's save change the 'status' field, since
 user B didn't modify that field.  I am using the hidden initial
 functionality to detect that user B has not changed the status field, and
 then I am setting self._meta.exclude to all fields in the form that were
 not changed by the user.  This all works fine the fields are non-m2m
 fields, but breaks down when an m2m field is placed in self._meta.exclude.

 Currently save_m2m() is defined like this:

 {{{
 def save_m2m():
 opts = instance._meta
 cleaned_data = form.cleaned_data
 for f in opts.many_to_many:
 if fields and f.name not in fields:
 continue
 if f.name in cleaned_data:
 f.save_form_data(instance, cleaned_data[f.name])
 }}}

 I find that if I define it like this instead, the m2m fields correctly are
 omitted from the save if they are in exclude.  This seems like more
 consistent and useful behavior to me.

 {{{
 def save_m2m():
 opts = instance._meta
 cleaned_data = form.cleaned_data
 for f in opts.many_to_many:
 if fields and f.name not in fields:
 continue
 if exclude and f.name in exclude:   <=== added this if clause
 continue
 if f.name in cleaned_data:
 f.save_form_data(instance, cleaned_data[f.name])
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner:  kmpm   

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by kmpm):

 sorry for not keeping this one up to date.
 The only thing supported for now is db_schema setting per model.
 I really would like some of the db related tickets to be solved first.
 Don't have the numbers now but there are some multi-db and GSOC ones that
 change more and related stuff that we realy shoud wait for. Thats at least
 my +1.
 And if anyone want's to pick this ticket up, please do.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2855: [patch] BooleanField should use False as default (unless provided)

[Django]

#2855: [patch] BooleanField should use False as default (unless provided)
---+
  Reporter:  SmileyChris   | Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version: 
  
Resolution:  wontfix   |  Keywords:  
BooleanField NullBooleanField
 Stage:  Design decision needed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by rlaa...@wiktel.com):

 For the record, this was fixed at some point.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12336: Infinite recursion in dir(UserSettingsHolder)

[Django]

#12336: Infinite recursion in dir(UserSettingsHolder)
-+--
  Reporter:  miracle2k   | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Core framework
  * needs_tests:  => 0
  * version:  1.1 => SVN
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12336: Infinite recursion in dir(UserSettingsHolder)

[Django]

#12336: Infinite recursion in dir(UserSettingsHolder)
---+
 Reporter:  miracle2k  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The implementation for __dir__ calls dir(self) - introduced here:

 http://code.djangoproject.com/changeset/11636

 To reproduce, simply do:

 {{{
 settings.configure({})
 dir(settings)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11838: Make syncdb understand "initialdata" directory

[Django]

#11838: Make syncdb understand "initialdata" directory
+---
  Reporter:  skorpan| Owner:  bkonkle   
  
Status:  assigned   | Milestone:  1.2   
  
 Component:  Uncategorized  |   Version:  SVN   
  
Resolution: |  Keywords:  syncdb loaddata 
initial_data
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by bkonkle):

 * cc: brandon.kon...@gmail.com (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11461: DebugNodeList breaks exceptions

[Django]

#11461: DebugNodeList breaks exceptions
-+--
  Reporter:  Glenn   | Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Template system |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by michaelg):

 * cc: micha...@activestate.com (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7800: GenericRelation doesn't respect changes from the default GenericForeignKey field names in the contenttypes framework

[Django]

#7800: GenericRelation doesn't respect changes from the default 
GenericForeignKey
field names in the contenttypes framework
-+--
  Reporter:  devinj  | Owner:  charmless
Status:  assigned| Milestone:   
 Component:  Contrib apps|   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  1
Needs_better_patch:  1   |  
-+--
Changes (by ramiro):

  * stage:  Accepted => Design decision needed

Comment:

 This ticket has grown to encompass three things:

  1. It asks for need for documentation of the `object_id_field` and
 `content_type_field` options of `GenericRelation`.
  2. It ask for validation of this stuff at model validation time.
  3. It includes a patch for a revamped implementation of the feature.

 Item 1 was dealt with in #10273 and #10303. I don't know which if any of
 the remaining two items are valid and so worth keeping as an open ticket.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner:  kmpm   

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by hejsan):

 Replying to [comment:42 oldium]:
 > The db_schema is already implemented in attached patches. There is no
 magic included, you just define a variable APP_SCHEMA (or any other name)
 at the top of the file and use it later on.
 Ok, great. Should I apply all the attached patches in order or just the
 last one?

 What do you think about the USE_APP_NAMES_AS_SCHEMA_NAMES idea? Is it
 doable?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner:  kmpm   

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by oldium):

 Replying to [comment:41 hejsan]:
 > Replying to [comment:40 oldium]:
 > >   class Meta:
 > > db_schema = APP_SCHEMA
 >
 > Is this something you have already implemented?

 The db_schema is already implemented in attached patches. There is no
 magic included, you just define a variable APP_SCHEMA (or any other name)
 at the top of the file and use it later on.

 > Can you provide a patch that would work with the current django
 development version? Or do you sync your github branch to the development
 version often?

 I don't have anything at the moment, maybe kmpm (alias crippledcanary) has
 more.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #399: Bigint field object needed

[Django]

#399: Bigint field object needed
---+
  Reporter:  jmad...@techie.com| Owner:  permon 
 
Status:  assigned  | Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  
sprintsept14, bigint
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by SmileyChris):

 Replying to [comment:65 permon]:
 > I am still looking for someone with running oracle instance who can
 confirm tests and correct admin behavior.

 The best thing you can do is keep on bring it up on the django-dev google
 group.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12335: Namespaces for applications

[Django]

#12335: Namespaces for applications
+---
 Reporter:  jtiai   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:
 Keywords:  core namespaces config  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Django should allow application names to use namespacing using standard
 Python notation {{{ package.package.myapp }}}.

 Currently requires application names to be unique within project
 INSTALLED_APPS settings and application name is only ''last'' part of
 complete package name.

 Django even reserves very generic application names like "admin", "auth"
 and "sessions"

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12334: GeoQuerySet creates invalid SQL on calls to `__nonzero__` or `__len__`

[Django]

#12334: GeoQuerySet creates invalid SQL on calls to `__nonzero__` or `__len__`
-+--
  Reporter:  wardi   | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by wardi):

  * needs_better_patch:  => 0
  * component:  Uncategorized => GIS
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12334: GeoQuerySet creates invalid SQL on calls to `__nonzero__` or `__len__`

[Django]

#12334: GeoQuerySet creates invalid SQL on calls to `__nonzero__` or `__len__`
---+
 Reporter:  wardi  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 {{{
 from django.contrib.gis.db import models
 from django.contrib.gis.geos import Point

 class Location(models.Model):
 point = models.PointField()

 bool(Location.objects.filter(point=Point(1,0)))
 }}}

 causes an exception in the regular django db layer (not the gis one), it
 looks like the implementation of `__nonzero__` and `__len__` in `QuerySet`
 are not properly overridden by `GeoQuerySet`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+--
  Reporter:  pixelcort   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Changes (by anonymous):

 * cc: ja...@dropp.co.uk (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11081: Page rendering fails after upgrading to r10703

[Django]

#11081: Page rendering fails after upgrading to r10703
-+--
  Reporter:  awatts  | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Core framework  |   Version:  SVN 
Resolution:  worksforme  |  Keywords:  getdefaultlocale mac
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 Replying to [comment:7 mertnuhoglu]:
 > Replying to [comment:6 kmtracey]:
 >
 > django 1.1.1 final version which is available for download in the
 website doesn't contain the lines that calculate DEFAULT_LOCALE_ENCODING.

 Yes, it does, really.  It contains exactly the code you can see on the
 website here:

 
http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/utils/encoding.py#L142

 I just downloaded a fresh copy, unpacked, and checked the file.  The code
 is there in the release file.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11081: Page rendering fails after upgrading to r10703

[Django]

#11081: Page rendering fails after upgrading to r10703
-+--
  Reporter:  awatts  | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Core framework  |   Version:  SVN 
Resolution:  worksforme  |  Keywords:  getdefaultlocale mac
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by mertnuhoglu):

 Replying to [comment:6 kmtracey]:

 django 1.1.1 final version which is available for download in the website
 doesn't contain the lines that calculate DEFAULT_LOCALE_ENCODING.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12333: CheckboxInput don't work with 0 and 1 value (considerd as Booleans)

[Django]

#12333: CheckboxInput don't work with 0 and 1 value (considerd as Booleans)
---+
 Reporter:  alexis_m   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords:  CheckboxInput Boolean  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Hello,

 I think I've discovered an unwanted behavior in the "render" method of the
 CheckboxInput class, or maybe I don't understand how it's designed to be
 used.

 When using the render() method, with a value of 0 or 1, the verification
 process, made by the following code:

 {{{
 if value not in ('', True, False, None):
 }}}

 prevents the "value" attribute to be shown.

 It's mainly because 1 and 0 are considéred equals to True and False.

 Here is my proposition to solve this:

 {{{
 if (value not in ('', None)) and str(value) not in ('False', 'True'):
 }}}

 Another option can be to use force_unicode from from django.utils.encoding
 on incoming values.

 Thanks

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner:  kmpm   

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by hejsan):

 Replying to [comment:40 oldium]:
 >   class Meta:
 > db_schema = APP_SCHEMA

 Is this something you have already implemented?

 Can you provide a patch that would work with the current django
 development version? Or do you sync your github branch to the development
 version often?

 This would certainly get things done, although it would be much more
 convenient to be able to have an app specific setting. Or have a global
 settings variable USE_APP_NAMES_AS_SCHEMA_NAMES = True. This would allow
 to put the standard django apps and 3rd party apps also into schemas.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #399: Bigint field object needed

[Django]

#399: Bigint field object needed
---+
  Reporter:  jmad...@techie.com| Owner:  permon 
 
Status:  assigned  | Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  
sprintsept14, bigint
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Changes (by permon):

  * stage:  Design decision needed => Accepted

Comment:

 Replying to [comment:64 anonymous]:
 You are right. Patch was updated, also tests were slightly modified. Tests
 were successfully run on these backends: sqlite3, mysql, postgresql,
 postgresql_psycopg2. I am still looking for someone with running oracle
 instance who can confirm tests and correct admin behavior.
 Also  changing stage to accepted due [comment:54 Richard Davies]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12332: {% blocktrans with value as variable %} syntax cannot parse literal values passed through filters

[Django]

#12332: {% blocktrans with value as variable %} syntax cannot parse literal 
values
passed through filters
-+--
 Reporter:  Alun Bestor  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  SVN   
 Keywords:  blocktrans i18n  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 As a contrived example:

 {{{
 {% blocktrans with "String Literal"|lower as lowercase_string %}Here is a
 lowercase string: {{ lowercase_string }}{% endblocktrans %}
 }}}

 This example will fail in Django 1.1 and 1.2 trunk with:

 {{{
 TemplateSyntaxError: variable bindings in 'blocktrans' must be 'with value
 as variable'
 }}}

 The example will be parsed successfully if the filter is omitted, or if
 the filtered value is a context variable instead of a literal (e.g.
 string_var|lower).

 One workaround for the parsing problem would be to use the following code:
 {{{
 {% with "String Literal"|lower as lowercase_string %}
 {% blocktrans with lowercase_string as lowercase_string %}Here is a
 lowercase string: {{ lowercase_string }}{% endblocktrans %}
 {‰ endwith %}
 }}}

 (In the contrived example it is of course unnecessary to use the lower
 filter on a literal value; the actual case came up with a custom filter
 which processes a value differently depending on active settings.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12331: get_display shows choices key, not value if field name contains underscore symbol

[Django]

#12331: get_display shows choices key, not value if field name contains 
underscore
symbol
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Template system   | Version:  SVN   
 Keywords:  choices, get_display  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 {{{
 CURRENCY_CHOICES = (
 (u"USD", u"$"),
 (u"EUR", u"€"),
 )
 buyer_currency = models.CharField(u"Price", choices = CURRENCY_CHOICES,
 max_length=3, default='USD')

 template:
 {{user.userprofile.get_buyer_currency_display|safe}} shows "USD"
 after rebuilding model with no underscore it works as it should:
 {{user.userprofile.get_buyercurrency_display|safe}} shows "$"
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.