Re: Problems with DatabaseCreation, table names, and index names
On 11/03/10 01:05, Russell Keith-Magee wrote: We have an incentive to fix it too -- #12977 points out that Django's own test suite runs foul of this problem. Ah, that's not good. 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. From my experiments, PostgreSQL is even worse; it will silently truncate the name without even raising a warning. You only know it's happened when you get to "relation already exists". 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. I don't particularly care about naming policy; South looks at the database's meta info to work out what constraints there are on any given column, it doesn't try and work out possible names, and anyone that does otherwise should really steal my code! 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. That sounds like a good idea to me; the amount of people this affects is so small, adding extra parameters probably won't be annoying for most people. 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. I agree as well; I'll be happy to write the patch when we get around to 1.3 coding time. Andrew -- 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
I'd suggest using PasteDeploy: http://packages.python.org/twod.wsgi/manual/paste-factory.html I can't see a reason to reinvent the wheel with a Django-specific thing, while this widely used method is rock-solid. It's the one used in frameworks like Pylons and TurboGears, On Feb 26, 7:11 am, 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
On Wed, Mar 10, 2010 at 6:31 PM, Matt Boersma wrote:
> 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.
>
This is a MySQL specific tip, but we store our DB configuration in a
local my.cnf, which can be made unreadable by developers/admins, like
so:
[djangodb]
database = abc
user = defghijk
password = lmnop
host = qrs.tuv.wxyz
We then instruct django to read from that my.cnf:
DATABASE_OPTIONS = { 'read_default_file' : DB_CONF_PATH,
'read_default_group' : 'djangodb' }
or 1.2-rc syntax, with a slave:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'OPTIONS': {
'read_default_file' : DB_CONF_PATH,
'read_default_group' : 'djangodb'
}
},
'slave': {
'ENGINE': 'django.db.backends.mysql',
'OPTIONS': {
'read_default_file' : DB_CONF_PATH,
'read_default_group' : 'slave_djangodb'
}
},
}
Cheers
Tom
--
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
This was the initial question: On Feb 26, 8:11 am, Jared Forsyth wrote: > I have been looking around for a way of managing user-configurable > application settings In this discussion we must IMHO different between "low-level settings", "admin configurable settings" and "user configurable settings": 1. low level setting - configuration that is needed to start up the project - Stored in settings.py - e.g.: database connection data 2. Admin configurable settings - project wide configuration - e.g.: "min. search term length", "min. time out between login" 2. User configurable settings - User specific configuration - e.g.: "Your preferred markup", "Your preferred JavaScript Editor" Admin- and user settings are not needed at start up, so they can be stored into the database. It should be possible to change them in a nice way, with validation. In my django-dbpreferences [1] app, the settings are organized with a form. A other problem with the current settings.py in django is the namespace. IMHO every app should have this own namespace. To handle variable name conflicts i organized it in this way: Every app had this own settings file, e.g: .../FooApp/Foo_settings.py VAR1 = "Bar" VAR2 = 123 In the global project settings, i do this: ... # Bind the FooApp settings to the name FOO from FooApp import Foo_settings as FOO try: # User can overwrite everything in his separated settings file from local_settings import * except ImportError: pass To access the settings, e.g.: from django.conf import settings def foobar_view(request): var1 = settings.FOO.VAR1 var2 = settings.FOO.VAR2 ... [1] http://code.google.com/p/django-dbpreferences/ Mfg. Jens -- 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.
GSOC: Some info about possible projects
Hello I am a cs student from belgium. I worked on the camera module of pygame for last years gsoc. I have used Django for 2 projects and would like to contribute as part of gsoc. I have taken a look at the SummerOfCode2010 page, and I am interested and capable to do the folowing projects: * auth User enhancement * Implement proper IPv6 support in django * Improvements to annotation/aggregation: - string concatentation, date operations, annotation of non- aggregate results, etc - maybe windowing functions (postgres/oracle) like: rank(), row_rank(), ... I have been looking at the current django code base to get a better idea of the scope of this projects. Maybe that some of you can give me some pointers about this projects, or if some of this projects are more requested then others... I can pick one of them that bets soots me and write a formal application with a timeline and some more info.. Grtz abe -- 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: GSOC: Some info about possible projects
On Fri, Mar 12, 2010 at 5:16 AM, ab3 wrote: > Hello > > I am a cs student from belgium. I worked on the camera module of > pygame for last years gsoc. > I have used Django for 2 projects and would like to contribute as part > of gsoc. > I have taken a look at the SummerOfCode2010 page, and I am interested > and capable to do > the folowing projects: > > * auth User enhancement > * Implement proper IPv6 support in django > * Improvements to annotation/aggregation: > - string concatentation, date operations, annotation of non- > aggregate results, etc > - maybe windowing functions (postgres/oracle) like: rank(), > row_rank(), ... > > I have been looking at the current django code base to get a better > idea of the scope of > this projects. Maybe that some of you can give me some pointers about > this projects, or > if some of this projects are more requested then others... Hi Abe, The "scope" of these projects is whatever you think you can achieve in the 12 weeks of the GSoC program. The auth.User enhancement is a big, long standing issue in Django. In short, the goal is to provide an answer to one of the most commonly answered questions on django-users: "How do I use my own model for User". Django's user model enforces some assumptions that aren't helpful for all applications. This isn't a project for the light hearted. I can't point you at anything that documents the solution we want to have implemented, because we don't know what that solution is yet. It will involve a lot of negotiation and design work with the community -- finding the right solution is just as important as writing the code. The other two projects are pretty much exactly what they say on the box -- improve IPv6 support (adding fields to handle IPv6 content), and add some new features to aggregation. Of the two, I would say that aggregation support has more meat on it. There are plenty of extra features that could be added, and lots of outstanding issues that need to be resolved with the existing aggregation support. 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.
Transactions in Model.clean()
First, here's the problem I'm having, and then I'll bring up my request. I have a model that looks like this (using dev version): class SecretModel(models.Model): some_unique_field = models.CharField(max_length=25, unique=True) # Notice this is unique. class MyModel(models.Model): secret_model = models.OneToOneField(SecretModel, editable=False) # spam = models.CharField(max_length=15) foo = models.IntegerField() def clean(self): SecretModel.objects.create(some_unique_field=self.spam) Now if I go do this: MyModel.objects.create(spam='john', foo='OOPS') # Obviously foo won't take 'OOPS' as it's an IntegerField. ERROR HERE MyModel.objects.create(spam='john', foo=5) # So try again here. ... IntegrityError because SecretModel with some_unique_field = 'john' already exists. If there is a way to handle this behavior already, I apologize for wasting your time. Otherwise, I'm suggesting the addition of transaction handling for model methods. Is this reasonable? -- 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: Transactions in Model.clean()
This message is inappropriate for this list. Before sending mail to Django discussion lists in the future, please read up on the difference between the django-developers list and the django-users list. -- "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.
