Re: Model validation
Hi, The code on github works (tests pass) but is not ready for production use. What you can do to help is test and mostly, write tests to help us get there. There will be a sprint on model-validation during pycon, which should resolve most of the outstanding issues. Honza Král E-Mail: honza.k...@gmail.com ICQ#: 107471613 Phone: +420 606 678585 On Mon, Mar 9, 2009 at 11:25 AM, David Reynolds wrote: > > Hi, > > I need to use some sort of model validation in a project I am working > on and I wondered what that status of > http://code.djangoproject.com/ticket/6845 is. > > Is the github code useable for production? Is there anything I can do > to help with it? Is there a recommended workaround for model > validation in the meantime? > > Thanks, > > David > > -- > David Reynolds > da...@reynoldsfamily.org.uk > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model validation
Hi Honza, Would this code be an approach I could take with my work on fixture? (See my message from a couple of days ago). Cheers, Ben 2009/3/10 Honza Král > > Hi, > The code on github works (tests pass) but is not ready for production > use. What you can do to help is test and mostly, write tests to help > us get there. There will be a sprint on model-validation during pycon, > which should resolve most of the outstanding issues. > > > > Honza Král > E-Mail: honza.k...@gmail.com > ICQ#: 107471613 > Phone: +420 606 678585 > > > > On Mon, Mar 9, 2009 at 11:25 AM, David Reynolds > wrote: > > > > Hi, > > > > I need to use some sort of model validation in a project I am working > > on and I wondered what that status of > > http://code.djangoproject.com/ticket/6845 is. > > > > Is the github code useable for production? Is there anything I can do > > to help with it? Is there a recommended workaround for model > > validation in the meantime? > > > > Thanks, > > > > David > > > > -- > > David Reynolds > > da...@reynoldsfamily.org.uk > > > > > > > > > > > -- Regards, Ben Ford ben.for...@gmail.com +447792598685 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket 10405 and documentation about using 'app.model' notation in FKs to other apps models
Hi,
While trying to get a grip on this [1]ticket about problems experienced
when using the 'otherapp.model' notation to the target model of a
Foreign Key when that model is located on another application. I went to
the relevant [2]docs:
"""
If you need to create a relationship on a model that has not yet been
defined, you can use the name of the model, rather than the model object
itself::
class Car(models.Model):
manufacturer = models.ForeignKey('Manufacturer')
# ...
class Manufacturer(models.Model):
# ...
Note, however, that this only refers to models in the same models.py
file -- you cannot use a string to reference a model defined in another
application or imported from elsewhere.
Changed in Django 1.0: Refering models in other applications must
include the application label.
To refer to models defined in another application, you must instead
explicitly specify the application label. For example, if the
Manufacturer model above is defined in another application called
production, you'd need to use...
It seems the two last paragraphs (from "Changed in Django 1.0"
onwards) contradict the paragraph inmediately above them.
Supporting this usage might mean we need to insert at least one
additional django.deb.models.get_apps() call (some of the places where
it has already been inserted so far have associated comments describing
doing that as a hack.)
Namely, from the cases reported in the ticket and associated threads it
seems it would need to be inserted in
django.core.urlresolvers._get_urlconf_module()
But if we don't need to support it we just can change this ticket
component to Documentation and correct the docs to delete the two last
paragraphs.
Am I missing something here?.
Regards,
--
Ramiro Morales
http://rmorales.net
1. http://code.djangoproject.com/ticket/10405
2.
http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: 'week_day' starting with sunday as first day of a week need to be fixed
On Mar 9, 11:48 am, Malcolm Tredinnick wrote: > So what??? Nobody actually does print out those standards and read them > and it takes approximately 3 seconds, if you think very slowly, to be > able to handle Sunday as the first day of the week if you were > previously handling Monday. True, i don't print them out but i'm always glad if i can refer to one. You can't imagine in what kind of hell you can get without standards, and that's the reason i write here. > There are some libraries that expect Monday to be the first day of the > week and others that expect to it to be Sunday. You'll never be able to > close your eyes and always use one value, so, in that respect, it > doesn't matter what we choose. 100% right, from the practical point of view. > Sunday is very well defined. There's absolutely no ambiguity over which > day of the week Sunday is. There is, however, quite genuine ambiguity > over which day of the week is "expected" to be the first day of the week > as even a casual perusal of this thread would show. > > A sentence saying "the first day of the week is Sunday" in the docs will > not be misunderstood, believe me. Hmm. True. But that's one of those points where somebody will cry out loud saying: "week_day does not what i expect it to do" (if he expects Monday as first day). And then you can refer to the docs and say "read there" and he will either be like "alright" or "why is Sunday the first day?". I personally find it very annoying when i have to work with different week_day implementations from platform to platform and i'm always happy if it just says "this thing here works after ISO XYZ" and i don't have to read any further because i know what it's going to do. I mean, that's the whole point of standards, read it once and the use it everywhere. > > Well maybe it's not the "most supported" or "most common" option, we > > don't know that for certain. But it's the option that most of > > developers can use without(!) a conversion so i think we should go for > > that. > > Basic logic: If it's not most supported or most common, then that > assertion is pretty much false by definition. The choices are basically > between Monday and Sunday, not Monday and Thursday or something. So if > Monday isn't the most common, Sunday will be. Alright, sorry. It _is_ the most used value. Python and nearly all modules _always_ use Monday as the first they of the week. Beside that you're right. > > By the way: > > Has anyone even noticed that in Python both weekday() and isoweekday() > > use Monday as the first day of the week??? > > Perhaps you could check ths sarcasm at the door? Everybody who's > responded in this thread has exhibited intelligence towards you. Sorry, i didn't want to be rude. It just have the feeling that ... well, i really don't know. I used so many national and international standards over the year and i always find it great if i have something i can rely upon. And it would just annoy me to see this feature going against the official international standard. Maybe i shouldn't spend so much energy on that. :/ > > So i think there should be > > no discussion about this anyway. Just use Python's standards and we're > > set. > > Or we could just use the value that matches what a number of our > databases (and a number of other programs) use and we're also set, since > it works well with all other code using those databases. BUT creates more code on the user side. That's the whole point of a framework - keep the complex and repeating stuff inside. > > Just one question: WHY should it reflect the options available for the > > database backends? > > You're simply answering a question with a question, in effect. It's an > essentially arbitrary decision, since there are arguments both ways. > Yes, you've added your own weights to the arguments, but at least > acknowledge that two sides exist. When it comes down to "why one or the > other" between two roughly equal choices, you can always ask "why not > the other way" and the answer is because we chose the way we did. You > can see from the history of this code that the decision was made > intentionally. I see that it was made intentionally and that's basically okay for me. And yes i acknowledge that there are arguments both ways. And of course someone could always ask "why not the other" way. And that's exactly the situation where i'd like to say "we did it that way because there are more arguments for this that for the other". And that's what's the case - one reason (because the databases are using it) for the "Sunday-side" and multiple reasons for the "Monday"-side. > > Since you want to work with that stuff on Python's > > side it should reflect the options given by Python. So that makes > > absolutely no sense! > > Incorrect, as noted above and elsewhere in this thread. Maybe i was a bit harsh as it partially makes sense but it still don't see why it is incorrect. > > That's no discussion about wether one will be unhappy or
Re: 'week_day' starting with sunday as first day of a week need to be fixed
On Mar 9, 8:13 pm, Karen Tracey wrote: > I still see no reason to change it. I, personally, haven't noticed any > convergence on a standard starting weekday of Monday in everyday life -- all > my wall calendars (3) start with Sunday, though my desk calendar starts with > Monday. Granted it's a bit of a nuisance that you have to adjust the output > of Python's isoweekday() to feed into this new lookup, but it isn't like all > uses of this new lookup are going to be starting off with a input datetime > object that you want to match the weekday of. I actually expect it'll be > more common to be feeding in results from a choice field or somesuch where > assignment of choice values to user-visible strings is done manually by the > programmer...no Python datetimes involved. Well that may be an argument. Maybe i won't have any problems with this at all. :) On a side note: I haven't noticed any problems with that in everyday life yet. BUT i had exactly this problem a few times before and i always found it very cumbersome to convert the values - mostly between the databases (that have no "standard") and my software and components that mostly follow the ISO standard. So that's my personal background for this matter and that's why i still think it's not the best choice. But it's a choice and the workaround is not that hard so i'll leave it "as is". Regards, Semmel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Thread-safety bug in WSGIHandler
I have found an incomplete-initialization bug the WSGIHandler when running under Apache mpm_worker with mod_wsgi. On the first request the WSGIHandler.__call__(...), we set up the middleware. There is a lock wrapping the load of the middleware, but the logic still allows incomplete initialization on other threads. Below is the block of code in question from django/core/handlers/wsgi.py (line 226): if self._request_middleware is None: self.initLock.acquire() # Check that middleware is still uninitialised. if self._request_middleware is None: self.load_middleware() self.initLock.release() Example: 1. Initial start or restart of the Apache instance 2. Thread T1 - a request comes in. self._request_middleware is None 3. Thread T1 - acquires the self.initLock, calls self.load_middleware() 4. Thread T2 - a request comes in (T1 is part of the way through self.load_middleware() 5. Thread T2 - self._request_middleware is not None, but it's not completely loaded either, continues with the request 6. Thread T1 - completes self.load_middleware(), release the lock The problem is the assignment of self._request_middleware is not atomic (it is created as an empty list and populated with append() in a loop. To fix this, we need an atomic assignment. I initially thought about changing load_middleware() to build the _request_middleware array in a local variable and then doing a single assignment to save it to self._request_middleware. While this would solve the problem, I thought that having the initialization test in WSGIHandler.__call__() test for what is essentially a side effect of self.load_middleware() is error prone. So, my proposed fix is to add a flag in WSGIHandler and then test for that flag in __call__(). I implemented this in our custom WSGI handler replacement and it worked perfectly. I will submit a ticket with patch to Django if the group agrees. Here is my fix: WSGIHandler.__init__(self): BaseHandler.__init__(self) self._middleware_loaded = False WSGIHandler.__call__(...): ... if not self._middleware_loaded: self.initLock.acquire() # Check that middleware is still uninitialised. if not self._middleware_loaded: self.load_middleware() self._middleware_loaded = True self.initLock.release() ... Travis Propeller.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Cache related values without needing to hit database twice
I think ORM should have some kind of caching. For example, in docs[1], when we do: >>> e = Entry.objects.get(pk=1) >>> e.blog # Hits database >>> e.blog # Don't hit database But let's imagine we have a third model named Author: class Author(models.Model): name = models.CharField(max_length=50) blog = models.OneToOneField(Blog) When we do: >>> a = Author.objects.get(pk=1) >>> b = a.blog # Hit's database >>> b.author # Hits database again What do you think in saving the author value in the blog instance if it is achieved through the author instance? It's something like telling blog who is his author in the moment you are retrieving it from the author. The same concept can be used in ForeignKey also. Whe we do: >>> b = Blog.objects.get(pk=1) >>> for entry in b.entry_set.all(): ...entry.blog # hits database to retrieve the blog in each iteration. What do you think about it? Vinícius Mendes Engenheiro de Computação Meio Código - A peça que faltava para o seu código! URL http://www.meiocodigo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Cache related values without needing to hit database twice
I think you should look at select_related() to solve most of those cases. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Cache related values without needing to hit database twice
On Tue, Mar 10, 2009 at 11:12 AM, Vinicius Mendes wrote: ... > What do you think in saving the author value in the blog instance if it is > achieved through the author instance? It's something like telling blog who > is his author in the moment you are retrieving it from the author. You're describing ye olde #17: http://code.djangoproject.com/ticket/17 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Changing DatabaseWrapper._cursor() to take a dict instead of settings
I'm working on adding multiple-database support to an application and
am building a custom manager that lets me specify which DATABASE_NAME
to use for a particular model. It looks something like this:
class OtherDatabaseManager(models.Manager):
"""
This Manager lets you set the DATABASE_NAME on a per-model basis.
"""
def __init__(self, database_name, *args, **kwargs):
models.Manager.__init__(self, *args, **kwargs)
self.database_name = database_name
def get_query_set(self):
qs = models.Manager.get_query_set(self)
qs.query.connection = self.get_db_wrapper()
return qs
def get_db_wrapper(self):
from django.db.backends.postgresql_psycopg2.base import DatabaseWrapper
# Monkeypatch the settings file. This is not thread-safe!
old_db_name = settings.DATABASE_NAME
settings.DATABASE_NAME = self.database_name
wrapper = DatabaseWrapper()
wrapper._cursor(settings)
settings.DATABASE_NAME = old_db_name
return wrapper
class MyModel(models.Model):
# ...
objects = OtherDatabaseManager('my_custom_database)
This is not unlike the code here:
http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
--
One ugliness about this is that it has to monkeypatch the settings
file in order to change the DATABASE_NAME, before passing it to
DatabaseWrapper._cursor(). So my proposal is to change
DatabaseWrapper._cursor() to accept a settings *dictionary* instead of
a settings *object*.
The only place in the Django codebase that calls
DatabaseWrapper._cursor() is BaseDatabaseWrapper.cursor() in
db/backends/__init__.py. That, plus the fact that this method name is
preceded by an underscore, leads me to believe there are no
backwards-incompatibility issues with making this change. But I'm
bringing it up here in case anybody wants to point out problems before
I commit it.
Adrian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, Mar 10, 2009 at 12:21 PM, Adrian Holovaty wrote:
>
> I'm working on adding multiple-database support to an application and
> am building a custom manager that lets me specify which DATABASE_NAME
> to use for a particular model. It looks something like this:
>
> class OtherDatabaseManager(models.Manager):
>"""
>This Manager lets you set the DATABASE_NAME on a per-model basis.
>"""
>def __init__(self, database_name, *args, **kwargs):
>models.Manager.__init__(self, *args, **kwargs)
>self.database_name = database_name
>
>def get_query_set(self):
>qs = models.Manager.get_query_set(self)
>qs.query.connection = self.get_db_wrapper()
>return qs
>
>def get_db_wrapper(self):
>from django.db.backends.postgresql_psycopg2.base import
> DatabaseWrapper
>
># Monkeypatch the settings file. This is not thread-safe!
>old_db_name = settings.DATABASE_NAME
>settings.DATABASE_NAME = self.database_name
>wrapper = DatabaseWrapper()
>wrapper._cursor(settings)
>settings.DATABASE_NAME = old_db_name
>return wrapper
>
> class MyModel(models.Model):
># ...
>objects = OtherDatabaseManager('my_custom_database)
>
> This is not unlike the code here:
> http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
> --
>
> One ugliness about this is that it has to monkeypatch the settings
> file in order to change the DATABASE_NAME, before passing it to
> DatabaseWrapper._cursor(). So my proposal is to change
> DatabaseWrapper._cursor() to accept a settings *dictionary* instead of
> a settings *object*.
>
> The only place in the Django codebase that calls
> DatabaseWrapper._cursor() is BaseDatabaseWrapper.cursor() in
> db/backends/__init__.py. That, plus the fact that this method name is
> preceded by an underscore, leads me to believe there are no
> backwards-incompatibility issues with making this change. But I'm
> bringing it up here in case anybody wants to point out problems before
> I commit it.
>
> Adrian
>
> >
>
I've been looking at adding multiple database support to Django for a little
while now and as a part of my plan of action the first step is to remove all
references to the global settings in django.db.backends.* and replace them
with a settings dict as you suggest(minus stuff like settings.DEBUG
obviously). My proposal goes a little further than yours however since I
propose passing the settings dict in into the constructor of the connection
itself, not in the _cursor method, the advantage here is that when we create
the connection we have all the information we need then.
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor wrote: > I've been looking at adding multiple database support to Django for a little > while now and as a part of my plan of action the first step is to remove all > references to the global settings in django.db.backends.* and replace them > with a settings dict as you suggest(minus stuff like settings.DEBUG > obviously). My proposal goes a little further than yours however since I > propose passing the settings dict in into the constructor of the connection > itself, not in the _cursor method, the advantage here is that when we create > the connection we have all the information we need then. Hey, this sounds like a good improvement (passing the settings to the constructor instead of _cursor). Do you have any patches or at least a link your proposal, if you've written one? I can't seem to find anything. Adrian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, Mar 10, 2009 at 3:46 PM, Adrian Holovaty wrote: > > On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor > wrote: > > I've been looking at adding multiple database support to Django for a > little > > while now and as a part of my plan of action the first step is to remove > all > > references to the global settings in django.db.backends.* and replace > them > > with a settings dict as you suggest(minus stuff like settings.DEBUG > > obviously). My proposal goes a little further than yours however since I > > propose passing the settings dict in into the constructor of the > connection > > itself, not in the _cursor method, the advantage here is that when we > create > > the connection we have all the information we need then. > > Hey, this sounds like a good improvement (passing the settings to the > constructor instead of _cursor). Do you have any patches or at least a > link your proposal, if you've written one? I can't seem to find > anything. > > Adrian > > > > I have a longer proposal that outlines a lot of the hard bits and implementation issues which is unfortunately trapped on a dead laptop right now, but I've got a seperate outline of the public API which you can see here: http://cometdemo.lshift.net:8080/greed/e8bd84ee/ . Once I have both of them put together into one document I'll sent the whole thing to django-dev for feedback as it's my intent to work on this for GSOC. As for the settings thing I don't have any code for it yet, but I can work on it. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, Mar 10, 2009 at 4:03 PM, Alex Gaynor wrote: > > > On Tue, Mar 10, 2009 at 3:46 PM, Adrian Holovaty wrote: > >> >> On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor >> wrote: >> > I've been looking at adding multiple database support to Django for a >> little >> > while now and as a part of my plan of action the first step is to remove >> all >> > references to the global settings in django.db.backends.* and replace >> them >> > with a settings dict as you suggest(minus stuff like settings.DEBUG >> > obviously). My proposal goes a little further than yours however since >> I >> > propose passing the settings dict in into the constructor of the >> connection >> > itself, not in the _cursor method, the advantage here is that when we >> create >> > the connection we have all the information we need then. >> >> Hey, this sounds like a good improvement (passing the settings to the >> constructor instead of _cursor). Do you have any patches or at least a >> link your proposal, if you've written one? I can't seem to find >> anything. >> >> Adrian >> >> >> >> > I have a longer proposal that outlines a lot of the hard bits and > implementation issues which is unfortunately trapped on a dead laptop right > now, but I've got a seperate outline of the public API which you can see > here: http://cometdemo.lshift.net:8080/greed/e8bd84ee/ . Once I have both > of them put together into one document I'll sent the whole thing to > django-dev for feedback as it's my intent to work on this for GSOC. > > As for the settings thing I don't have any code for it yet, but I can work > on it. > > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero > I've gone ahead and filed a ticket and posted an initial patch: http://code.djangoproject.com/ticket/10459 . The patch seems to work but it doesn't hit any of the test db stuff. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, 2009-03-10 at 12:21 -0500, Adrian Holovaty wrote: [...] > One ugliness about this is that it has to monkeypatch the settings > file in order to change the DATABASE_NAME, before passing it to > DatabaseWrapper._cursor(). So my proposal is to change > DatabaseWrapper._cursor() to accept a settings *dictionary* instead of > a settings *object*. I think the direction is a good one. Something that far down the chain probably shouldn't have a hard dependency on settings. We insulate the users from needing to pass around settings everywhere manually, but it's not too onerous to do so ourselves. Whether you pass the dictionary to _cursor or to the constructor as Alex proposes is for you to decide, I think. We can evolve that over time if we need to. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Thread-safety bug in WSGIHandler
On Tue, 2009-03-10 at 10:30 -0400, Travis Terry wrote: [...] > So, my proposed fix is to add a flag in WSGIHandler and then test for > that flag in __call__(). Preferable to construct the list as a local variable and then assign it to the attribute in a single instruction. Assignment is atomic, so the attribute will either be populated or not in that case and can act as its own flag. Avoids adding yet another variable and matches what we do in a bunch of other places. Apart from that your analysis looks correct. Please open a ticket in Django's Trac do that this doesn't get forgotten. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, Mar 10, 2009 at 8:56 PM, Malcolm Tredinnick < malc...@pointy-stick.com> wrote: > > On Tue, 2009-03-10 at 12:21 -0500, Adrian Holovaty wrote: > [...] > > One ugliness about this is that it has to monkeypatch the settings > > file in order to change the DATABASE_NAME, before passing it to > > DatabaseWrapper._cursor(). So my proposal is to change > > DatabaseWrapper._cursor() to accept a settings *dictionary* instead of > > a settings *object*. > > I think the direction is a good one. Something that far down the chain > probably shouldn't have a hard dependency on settings. We insulate the > users from needing to pass around settings everywhere manually, but it's > not too onerous to do so ourselves. > > Whether you pass the dictionary to _cursor or to the constructor as Alex > proposes is for you to decide, I think. We can evolve that over time if > we need to. > > Regards, > Malcolm > > > > > > I've posted a patch, but I'd like to here from one of the external DB backend maintainers, I know we technically don't have any backwards compatibility requirement here, but I don't think we want to jerk them around too much. Another thing is I want to encourage all external backends to use DATABASE_OPTIONS for extra options, rather than additional settings, that way they can be DB specific once we have multidb. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ModelForm field ordering
Currently the order of fields in a ModelForm is always the same as their order on the Model with any many to many fields coming last. -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ModelForm field ordering
Aren't I smart: Currently the order of fields in a ModelForm is always the same as their order on the Model with any many to many fields coming last. This is obviously disadvantageous since often a developer/designer wants them to be in a different order. This is ticket #8164 and #6953 . The suggestion in #8164 is to have the fields be in the order that they are in the fields Meta option. The question here is whether this is a backwards compatibility issue as currently they're ordered woudln't be affected if a developer had them in an arbitrary order. Or for #6953 if a developer was expecting them to always be last. I'm looking for opinions as to whether this qualifies as a backwards compatibility issue as to the best of my scavengering this isn't documented behavior anywhere. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings
On Tue, Mar 10, 2009 at 9:15 PM, Alex Gaynor wrote: > I've posted a patch, but I'd like to here from one of the external DB > backend maintainers, I know we technically don't have any backwards > compatibility requirement here, but I don't think we want to jerk them > around too much. Another thing is I want to encourage all external backends > to use DATABASE_OPTIONS for extra options, rather than additional settings, > that way they can be DB specific once we have multidb. Thanks for the patch, Alex. I had already started doing it on my own and was pleased to see we came up with almost exactly the same solution. The main differences are that I called it BaseDatabaseWrapper.settings_dict instead of BaseDatabaseWrapper.settings (to make it clear it's a dictionary and make it grepable) and I assigned to a local settings_dict variable whenever the code needed to refer to self.settings_dict many times. http://code.djangoproject.com/changeset/10026 This will most probably break external database backends, so I'll send out a separate django-developers note about that, in hopes of getting their attention. Adrian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
django.db.backends refactored; hacks and third-party backends might break
To the maintainers of third-party Django database backends (like DB2, etc.) and whoever else is hacking/patching/corrupting the code in django.db.backends for fun or profit -- With the help of Alex Gaynor, I've just checked in a light refactoring of the database backends such that Django database objects (BaseDatabaseWrapper instances) now keep track of their own database settings. This makes it easier to add multiple-database support to Django, and it's cleaner overall for the connection objects to deal with dictionaries rather than bulky Django settings module objects. This is backwards-compatible for end users but will likely break third-party database backends or any other code that hacks around in there. Specific API changes are: * BaseDatabaseWrapper.__init__() now takes a settings_dict instead of a settings module. It's called settings_dict to disambiguate, and for easy grepability. This should be a dictionary containing DATABASE_NAME, etc. * BaseDatabaseWrapper has a settings_dict attribute instead of an options attribute. BaseDatabaseWrapper.options is now BaseDatabaseWrapper['DATABASE_OPTIONS'] * BaseDatabaseWrapper._cursor() no longer takes a settings argument. * BaseDatabaseClient.__init__() now takes a connection argument (a DatabaseWrapper instance) instead of no arguments. The full changeset is here: http://code.djangoproject.com/changeset/10026 It's a pretty straightforward refactoring, but if you have any technical questions on how to upgrade third-party backends or your own hacks, please just respond to this and I'll try to help. If you don't get a response within a day or so, just e-mail me off-list to get my attention. Adrian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.db.backends refactored; hacks and third-party backends might break
On Tue, 2009-03-10 at 22:54 -0500, Adrian Holovaty wrote: [...] > The full changeset is here: http://code.djangoproject.com/changeset/10026 > > It's a pretty straightforward refactoring, but if you have any > technical questions on how to upgrade third-party backends or your own > hacks, please just respond to this and I'll try to help. If you don't > get a response within a day or so, just e-mail me off-list to get my > attention. One tip for third-party providers wanting to provide a backend that works on both 1.0.x and 1.1 and later. Remember that django.VERSION is a useful tuple and will soon read (1, 1, 0, 'beta', *), which is probably be a useful thing to trigger off for when to switch to the newer internal API. Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Google Summer of Code 2009
Hello all, On Mar 6, 9:13 pm, Jacob Kaplan-Moss wrote: > On Fri, Mar 6, 2009 at 4:07 AM, Petar Marić wrote: > > Will Django be participating in the Google SoC event this year? > > We'll be applying, yes. Did Django apply for GSoC 2009(seems like Google is already accepting Org Applications till 13th this month)? If so can some one kindly link me to the Ideas page? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
django in javascript
I just read an article at, http://www.b-list.org/weblog/2006/jul/04/javascript-orm-and-hding-sql/ . First I'll introduce myself, I'm a not so experienced web developer concluding graduation doing my final thesis about django and Gears. I completely understand the point about not having an AJAX and agree with that, and I'm not here to argue that. But during my research I found that a javascript library may be needed in the future to mimic aspects of django on client side. You are probably fluent with Gears, Adobe AIR, Jaxer or the HTML5 draft. And you probably know about the trend of getting web applications offline, this usually means that a lot of code has to be rewritten on javascript to get your application offline. I think that it goes against django DRY principles. It would be cool to work with model objects in javascript like I do in python. This has nothing to do with user choice since it is mainly back stage work, it's like having a subset of django inside your browser. At first I thought it was something to hard to try, then I found 2 pieces of code that do what I imagined but with active record ActiveRecord.js [1] and JazzRecord[2]. In my mind I should be able to work in javascript manipulating model objects just like I do in the server side, in the perfect world I should be able to access all django core libs, like forms, models etc, but if only we had an implementation of the ORM it would be of great help. I'm not sure if I understand all implications of this but I just wanted to know your thoughts on the subject. Thanks [1] http://activerecordjs.org/ [2] http://www.jazzrecord.org/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
