Re: GSoC - Class based serializers

2010-03-10 Thread Russell Keith-Magee 
On Wed, Mar 10, 2010 at 7:56 AM, Renato Garcia Pedigoni
 wrote:
> Hi folks
> My name is Renato, I'm currently studying Biomedical Informatics at the
> University of Sao Paulo, in Brazil.
> Last year I tried a GSoC slot with a declarative syntax serializer project
> for Django. Reading the 2010's ideas for GSoC I found it again, so I decided
> to try again, improving my proposal.
> If someone has moment and wants read (and if possible) discuss it here's my
> proposal:
> https://docs.google.com/Doc?docid=0AcnuqDbQa1rGZGMzdng3cW1fMTE2aHJtMzZkZnA&hl=pt_BR
> Thanks a lot

My comments essentially echo those of Alex.

 * A generic view that works with the serializer is probably a good
idea, but is orthogonal to the task of building a customizable
serializer. The serializer should be standalone. If you want to
include a generic view component in your proposal, feel free, but it
shouldn't be tightly coupled with the serialization component.

 * Your schedule is so vague it borders on being comical. I generally
use the rule of thumb that if a proposal contains a body of work
longer than a week, the person making the proposal doesn't understand
the problem they are trying to solve. In this case, your timeline
doesn't really provide any detail beyond that we already have from the
generic GSoC schedule.

 * When we say "customizable serializers", we mean it. The ideal end
goal is that you should be able to output any object (or list of
objects), in any format, to any depth, with any additional
information. This includes, but is not limited to:

 * Serializing nested structures (of arbitrary depth)
 * Serializing subsets of model attributes
 * Serializing non-database attributes/properties
 * Serialized output that doesn't match the current default output
format (i.e., a model in JSON doesn't have to be {"pk": XX, "model":
"myapp.foo", "fields": {...}} )
 * Serialized output format that can change on a per-model basis
 * Serialized output format that can change based on where in the
output tree the object is located (e.g., output the full User object
if it's included from within model X, but only output the username if
its included from within model Y)
 * In an XML context, control over the tags, namespaces, attributes
and nesting structures in the final XML
 * In a JSON/YAML context, control over the use of lists, dictionaries
etc, as well as the choice of key names for dictionaries.

In short, anywhere we have made an arbitrary design decision with
Django's existing serializers, that decision should be customizable as
an end user.

The proof of concept that you are on the right path is that you should
be able to provide a serializer declaration that defines the current
serialization formats. That is, I should be able to read your
serializer definition and determine how to produce output that is
compatible with Django's existing serializers.

Yours,
Russ Magee %-)

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Joan Miller 
Whatever configuration system using variables of a language is a
disaster and it's going not maintainable as has been showed in Django.

My solution was to use YAML, and then to use a class to convert it to
Python. Features:

* The python configuration is only re-built if yaml config. has been
changed.
* It can add some configuration depending of some variable, as debug.
See in lines where is '?'.
* It adds the absolute paths where it's necessary.

- YAML config. initial => http://pastebin.com/CVqGD1eL
- Python generated => http://pastebin.com/AB4FaBgy

On 26 feb, 07:11, Jared Forsyth  wrote:
> I have been looking around for a way of managing user-configurable
> application settings, and the only solution I have found is dbsettings,
> which looks like it hasn't been touched in 3 years.
> So, I would like to know: is dbsettings dead? Or is there a different
> generally accepted method for having user-friendly app settings? (e.g. don't
> require code modification)
>
> I think that this idea is pretty essential to django's ease of use; there
> are many applications which have (or should have) settings which only effect
> UI or minor behavioral issues, and shouldn't require a server restart to
> effect (and imo shouldn't require server write access). It seems that the
> most viable solution would be to have a database managed settings system (in
> the form of a .contrib module) which would manage this. It also seems that
> having such an infrastructure in place would really encourage app
> maintainers to have more settings, thereby making the apps even more
> portable.
>
> Any thoughts?
>
> Thanks,
> Jared

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Russell Keith-Magee 
On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller  wrote:
> Whatever configuration system using variables of a language is a
> disaster and it's going not maintainable as has been showed in Django.

That's a pretty wild assertion to make without any evidence, and it's
completely contrary to my personal experience. Care to back it up? In
what way has Django demonstrated that using a programming language for
configuration files is a disaster?

Yours,
Russ Magee %-)

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Joan Miller 
It's a disaster from the maintenance view point. If it were not so,
then people would not be proposing to refactor the settings as has
been made in Pinax, or from multiple posts so many times.

This is nothing new. Many people dislikes that kind of configuration,
of the same that many people hates java by its fu**ing XML config.
files.

On 10 mar, 13:49, Russell Keith-Magee  wrote:
> On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller  wrote:
> > Whatever configuration system using variables of a language is a
> > disaster and it's going not maintainable as has been showed in Django.
>
> That's a pretty wild assertion to make without any evidence, and it's
> completely contrary to my personal experience. Care to back it up? In
> what way has Django demonstrated that using a programming language for
> configuration files is a disaster?
>
> Yours,
> Russ Magee %-)

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Gary Reynolds 
I really don't see how your YAML file is any more maintainable than Django's
settings.py approach? If anything, I would argue that it is less
maintainable, as you would have to maintain not only your YAML files moving
forward, but also the code which transposes it into a settings.py.

On Wed, Mar 10, 2010 at 2:16 PM, Joan Miller  wrote:

> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.
>
> This is nothing new. Many people dislikes that kind of configuration,
> of the same that many people hates java by its fu**ing XML config.
> files.
>
> On 10 mar, 13:49, Russell Keith-Magee  wrote:
> > On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller  wrote:
> > > Whatever configuration system using variables of a language is a
> > > disaster and it's going not maintainable as has been showed in Django.
> >
> > That's a pretty wild assertion to make without any evidence, and it's
> > completely contrary to my personal experience. Care to back it up? In
> > what way has Django demonstrated that using a programming language for
> > configuration files is a disaster?
> >
> > Yours,
> > Russ Magee %-)
>

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Chuck Harmston 
1) In implementation, how is a YAML configuration file any different than
the Java/XML example that you offered? Syntactical differences between XML
and YAML aside, both systems define settings in markup languages (which by
definition have minimal capability for logic) that are eventually parsed (by
potentially faulty parses) into programming language datatypes.

2) The beauty of a programming language configuration system like Django's
is that it gives developers the option and ability to refactor settings
systems in ways that make sense to them and their projects.

For example, it provides you with the flexibility to keep settings in a YAML
file, if you so choose. My use case is a bit unique: I wanted
environment-specific (e.g. dev, staging, production) settings
overrides, kept in source-controlled files unless they were of sensitive
nature (DATABASE_PASSWORD, SECRET_KEY, etc). Python's flexibility gave me
the ability to turn settings into a full-blown module, with magic-keyworded
imports based on the machine's hostname and path of the settings module.

This flexibility is not by accident.

On Wed, Mar 10, 2010 at 8:16 AM, Joan Miller  wrote:

> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.
>
> This is nothing new. Many people dislikes that kind of configuration,
> of the same that many people hates java by its fu**ing XML config.
> files.
>
> On 10 mar, 13:49, Russell Keith-Magee  wrote:
> > On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller  wrote:
> > > Whatever configuration system using variables of a language is a
> > > disaster and it's going not maintainable as has been showed in Django.
> >
> > That's a pretty wild assertion to make without any evidence, and it's
> > completely contrary to my personal experience. Care to back it up? In
> > what way has Django demonstrated that using a programming language for
> > configuration files is a disaster?
> >
> > Yours,
> > Russ Magee %-)
>
> --
> 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.
>
>

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Russell Keith-Magee 
On Wed, Mar 10, 2010 at 10:16 PM, Joan Miller  wrote:
> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.
>
> This is nothing new. Many people dislikes that kind of configuration,
> of the same that many people hates java by its fu**ing XML config.
> files.

I must be seriously missing the point here, because I can't reconcile
your comments with my experience. I can't speak to what is going on
internal to the Pinax community, but your claim that the suggestion
has been made in "multiple posts so many times" certainly doesn't
reflect my recollection of django-dev and django-users activity.

I will openly admit that there is an issue with Django configuration
-- specifically, that Django doesn't make a distinction between
application settings and operations settings. In an enterprise
context, this can cause difficulty because the operational deployment
of a project shouldn't affect the configuration of applications in a
project, and vice versa. There can also be issues of data hiding --
for example, developers shouldn't know production database passwords.

I fail to see how using YAML, XML, or any other text-based format
improves anything from a "maintenance" point of view. It's Yet Another
Text Format For Configuration. The only difference is that *ML it
isn't as flexible as Python, because you don't have the capabilities
of a programming language.

Yours,
Russ Magee %-)

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Brian Rosner 

On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:

> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.

Like I mentioned in the post you made to the pinax-core-dev mailing list the 
problem Pinax is trying to solve is *not* because the settings are written in 
Python, but rather loading order and scope. Many projects quickly realize that 
running a Django project with a single settings file is nearly impossible with 
different environments all interacting with a single code base. Some projects 
turn to importing a local_settings.py file which is what Pinax currently does. 
This has worked wonderful for us for years. However, there has always been a 
scoping issue. It was difficult to easily change settings defined at the 
"global" level (this being project-wide settings that are environment 
agnostic). You'd have to copy them to the local_settings.py and add in extra 
values or remove existing values. One approach to solve this problem is to flip 
the loading order (imports happen at the settings.py level including the 
project level settings). While this works it presents a problem to usability. 
It would require an extra step on behalf of the user to either copy or create a 
missing settings file to run. This was a non-starter in Pinax since a 
fundamental goal is to get up and go once you've created the project. We've 
ultimately ended up on the solution Carl gave which can be read on our mailing 
list.

I don't see how your YAML configuration solves any of these problems. You'd 
have to create a similar mechanism with where you parse YAML files and then you 
are solving the same problem we are. If there is a solution you have in mind 
that magically solves everyone's problem nicely then present that instead of 
hand waving.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Jared Forsyth 
As far as a solution that "magically solves everyone's problem nicely",
that's what django-appsettingsis
trying to be :). It handles quite nicely the issues of scoping and
maintainability that you discussed, organizing everything in a pythonic
manner.

Jared

On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner  wrote:

>
> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:
>
> > It's a disaster from the maintenance view point. If it were not so,
> > then people would not be proposing to refactor the settings as has
> > been made in Pinax, or from multiple posts so many times.
>
> Like I mentioned in the post you made to the pinax-core-dev mailing list
> the problem Pinax is trying to solve is *not* because the settings are
> written in Python, but rather loading order and scope. Many projects quickly
> realize that running a Django project with a single settings file is nearly
> impossible with different environments all interacting with a single code
> base. Some projects turn to importing a local_settings.py file which is what
> Pinax currently does. This has worked wonderful for us for years. However,
> there has always been a scoping issue. It was difficult to easily change
> settings defined at the "global" level (this being project-wide settings
> that are environment agnostic). You'd have to copy them to the
> local_settings.py and add in extra values or remove existing values. One
> approach to solve this problem is to flip the loading order (imports happen
> at the settings.py level including the project level settings). While this
> works it presents a problem to usability. It would require an extra step on
> behalf of the user to either copy or create a missing settings file to run.
> This was a non-starter in Pinax since a fundamental goal is to get up and go
> once you've created the project. We've ultimately ended up on the solution
> Carl gave which can be read on our mailing list.
>
> I don't see how your YAML configuration solves any of these problems. You'd
> have to create a similar mechanism with where you parse YAML files and then
> you are solving the same problem we are. If there is a solution you have in
> mind that magically solves everyone's problem nicely then present that
> instead of hand waving.
>
> Brian Rosner
> http://oebfare.com
> http://twitter.com/brosner
>
> --
> 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.
>
>

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Matt Boersma 
On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner  wrote:
>
> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:
>
>> It's a disaster from the maintenance view point. If it were not so,
>> then people would not be proposing to refactor the settings as has
>> been made in Pinax, or from multiple posts so many times.
>
> Like I mentioned in the post you made to the pinax-core-dev mailing list the 
> problem Pinax is trying to solve is *not* because the settings are written in 
> Python, but rather loading order and scope. Many projects quickly realize 
> that running a Django project with a single settings file is nearly 
> impossible with different environments all interacting with a single code 
> base. Some projects turn to importing a local_settings.py file which is what 
> Pinax currently does. This has worked wonderful for us for years.
> [snip]

The local_settings.py convention (thanks, Pinax!) has worked well for
us in an environment with multiple dev, test, and production server
tiers.  We solve the DATABASE_PASSWORD= issue by only allowing the
DBAs access to local_settings.py on production, and having an
svn:ignore rule that prevents anyone from accidentally checking it in
to version control.

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

Porting _django_bash_completion to Windows Powershell

2010-03-10 Thread guillermooo 
** I might be posting in the wrong place. Apologies if I do, but this
felt like the right place to ask! **

Hi!

I'm trying to port Django's django_bash_completion script to Windows
Powershell, but I only know so much bash, so I'd need a little help in
understanding what's going on.

As far as I understand from reading the code, it just looks at the
arguments to "complete" to see whether they look something like this:

python manage.py

However, I don't see any call to an external script (bash or python).
How do you go from there, once you know you need the candidate
completions for the manage.py script? I can think of a few ways of
accomplishing this, but I'd rather see the standard implementation the
Django devs have come up with.

Thanks!
Guillermo

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

Porting _django_bash_completion to Windows Powershell

2010-03-10 Thread guillermooo 
** I might be posting in the wrong place. Apologies if I do, but this
felt like the right place to ask! **

Hi!

I'm trying to port Django's django_bash_completion script to Windows
Powershell, but I only know so much bash, so I'd need a little help in
understanding what's going on.

As far as I understand from reading the code, it just looks at the
arguments to "complete" to see whether they look something like this:

python manage.py

However, I don't see any call to an external script (bash or python).
How do you go from there, once you know you need the candidate
completions for the manage.py script? I can think of a few ways of
accomplishing this, but I'd rather see the standard implementation the
Django devs have come up with.

Thanks!
Guillermo

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

Problems with DatabaseCreation, table names, and index names

2010-03-10 Thread Andrew Godwin 

Hi all,

I'm posting this here, not as a ticket, as I'm not entirely sure it's 
Django's problem, and so would like some input*.


[Base]DatabaseCreation has a method sql_indexes_for_field, which, 
handily, returns the SQL indexes for a field. Less usefully, both 
PostgreSQL and MySQL have limits on the length of table/index names (63 
and 50 bytes by default, respectively).


Firstly, this means that if you have a very long model (table) name 
(say, 64 characters), Django's syncdb thinks it's not in the database 
(since your database has truncated the table name, and they now don't 
match), and tries to add it every time you run syncdb. This is an issue 
to itself, and should probably have either a more useful error or be 
fixed, although it's not easy to detect this has happened.



Secondly, if you have an indexed field on that same model, or two 
indexed fields with common prefixes on a model with a slightly shorter 
name, the method will happily spit out SQL with index names that are 
identical to the table/other index name when truncated to 63 characters, 
meaning the indices aren't added.


The reason I came across this is because a South user has filed a 
similar bug against South that I traced back to this behaviour (South 
uses sql_indexes_for_field, as it means special GeoDjango indexes get 
created as well). I have, however, replicated the bug with plain syncdb, 
using the following Django model:


class 
VeryLongModelNameThatHappensToBeOverSixtyThreeCharsLongEventually(models.Model):


my_slightly_less_long_field_name = models.IntegerField(db_index=True)
my_slightly_more_long_field_name = models.IntegerField(db_index=True)

The question is, is it even worth fixing? I'm tempted to conclude that 
you're limited to shorter model/field names by your database (or use 
db_table/db_column), but there's also the possibility of that method 
using a much shorter way of generating the names (i.e. using the first 
40 bytes or so, then appending an 8-byte hash of the rest). I can easily 
write and submit a patch to change the function to use this behaviour - 
we used to do it in South, before I started using the ``creation`` 
methods - but it's catering to such a small audience I'm not sure it's 
worth it, and documenting this behaviour might be a better solution.


Andrew

* Providing it doesn't significantly impact fixing of actual Django 
bugs, that affect more than 0.01% of the users.


--
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: Problems with DatabaseCreation, table names, and index names

2010-03-10 Thread James Bennett 
On Wed, Mar 10, 2010 at 4:55 PM, Andrew Godwin  wrote:
> The question is, is it even worth fixing? I'm tempted to conclude that
> you're limited to shorter model/field names by your database (or use
> db_table/db_column), but there's also the possibility of that method using a
> much shorter way of generating the names (i.e. using the first 40 bytes or
> so, then appending an 8-byte hash of the rest). I can easily write and
> submit a patch to change the function to use this behaviour - we used to do
> it in South, before I started using the ``creation`` methods - but it's
> catering to such a small audience I'm not sure it's worth it, and
> documenting this behaviour might be a better solution.

At first glance, my preferred solution is:

1. Document (probably in the database notes) the length constraints
for table names and how they affect index names.

2. Maybe a bit of a pony: have the backends know the maximum table
length for the DBs they handle. Then we can have syncdb and other
tools raise model-class validation errors and tell people to use
db_table to avoid the issue.

As for timing: I don't think this is critical enough for 1.2, but it's
something we should do and probably could go immediately on the 1.3
milestone.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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: Porting _django_bash_completion to Windows Powershell

2010-03-10 Thread Russell Keith-Magee 
On Thu, Mar 11, 2010 at 4:12 AM, guillermooo
 wrote:
> ** I might be posting in the wrong place. Apologies if I do, but this
> felt like the right place to ask! **
>
> Hi!
>
> I'm trying to port Django's django_bash_completion script to Windows
> Powershell, but I only know so much bash, so I'd need a little help in
> understanding what's going on.
>
> As far as I understand from reading the code, it just looks at the
> arguments to "complete" to see whether they look something like this:
>
>    python manage.py
>
> However, I don't see any call to an external script (bash or python).
> How do you go from there, once you know you need the candidate
> completions for the manage.py script? I can think of a few ways of
> accomplishing this, but I'd rather see the standard implementation the
> Django devs have come up with.

There's no external script; Bash does command line completion by
calling the actual command with some special environment variables --
specifically, COMP_WORDS and COMP_CWORD environment variables.

http://www.gnu.org/software/bash/manual/bash.html#lbCV

Internally, the autocompletion is done using the
ManagementUtility.autocomplete() method, line 264 of
django/core/management/__init__.py.

Yours,
Russ Magee %-)

-- 
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: Problems with DatabaseCreation, table names, and index names

2010-03-10 Thread Russell Keith-Magee 
On Thu, Mar 11, 2010 at 7:13 AM, James Bennett  wrote:
> On Wed, Mar 10, 2010 at 4:55 PM, Andrew Godwin  wrote:
>> The question is, is it even worth fixing? I'm tempted to conclude that
>> you're limited to shorter model/field names by your database (or use
>> db_table/db_column), but there's also the possibility of that method using a
>> much shorter way of generating the names (i.e. using the first 40 bytes or
>> so, then appending an 8-byte hash of the rest). I can easily write and
>> submit a patch to change the function to use this behaviour - we used to do
>> it in South, before I started using the ``creation`` methods - but it's
>> catering to such a small audience I'm not sure it's worth it, and
>> documenting this behaviour might be a better solution.
>
> At first glance, my preferred solution is:
>
> 1. Document (probably in the database notes) the length constraints
> for table names and how they affect index names.
>
> 2. Maybe a bit of a pony: have the backends know the maximum table
> length for the DBs they handle. Then we can have syncdb and other
> tools raise model-class validation errors and tell people to use
> db_table to avoid the issue.

We have an incentive to fix it too -- #12977 points out that Django's
own test suite runs foul of this problem.

Just documenting the problem isn't really a solution, IMHO. MySQL is
the fly in the ointment here, because it doesn't raise errors for a
long index name: it raises a warning and truncates the name. If you
have two similarly named long fields... hilarity ensues. At the very
least, we should be raising validation errors. Preferably, this would
be at a consistent length (rather than a backend dependent length) so
that you don't accidentally write a model that is fine under Postgres,
but can't be synchronized under MySQL.

However, I'm not sure whether truncation+hashing would improve things.
Hashing has the advantage of allowing any name you want, but it does
result in some less-than-pretty database names. It also means
introducing a change in naming policy, and putting on my "hey, I used
to run a migration project too" hat -- changes in naming policy in the
base project were really annoying to track and handle.

If we do go with the validation approach, I would make one additional
suggestion. You can manually specify database table names, but you
can't (currently) manually specify index names. Given that long index
names are the bigger problem (since they are composed from database
table and column names), we might also need to introduce a syntax to
allow manual index naming. For example, we could allow
db_index='foobar' to manually specify an index name; db_index=True
would continue to use the default generated name.

> As for timing: I don't think this is critical enough for 1.2, but it's
> something we should do and probably could go immediately on the 1.3
> milestone.

Agreed.

Yours,
Russ Magee %-)

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

Proposal - hook to modify links in object-tools

2010-03-10 Thread George Karpenkov 
Currently to add a link to object-tools one has to modify a template.

I think that in most cases it would be much easier to do that through
python - if admin actions have a mechanism for removing existing ones/
adding new ones why object-tools does not?

Sometimes it's impossible to modify an admin template - ie providing
an admin mixin

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