Re: Proposal: user-friendly API for multi-database support
Oops looks like I got distracted and hit send mid-thought. That last part is supposed to be: Obviously this function could get very complicated for a heavily sharded setup, but sharding is complicated by definition, so where that complexity goes isn't necessarily relevant. Letting this logic live in a function outside the apps allows for immense flexibility over time: if you upgrade your database server and this allows you to host two databases that were previously on distinct machines, all you have to do is modify that file. In the case of sharding, if you start out with a dataset that works fine on a single server, you don't do anything in teh function. Once you start sharding, you modify the function to reflect that. Cheers. Mike. On Sep 29, 10:25 pm, mihasya <[EMAIL PROTECTED]> wrote: > So, I'm still learning my way around the deeper parts of the codebase, > but at first glance the "function pointed to from settings.py" > approach seems best. This way, the connection management is completely > opaque to the model. If that function isn't defined, it can just fall > back to the default connection. This requires minimal changes to the > base model (to start with, anyway), and gives the developer > finegrained control over what queries go where - as fine grained as > they want. We can then build on that, adding "shortcuts" for basic use > cases, like defining a cluster of slaves to balance reads on etc. for > more "run-of-the-mill" problems. > > A distinct advantage of this approach is that it can be built up very > gradually. We can start with literally nothing - just a hook in the > model class to call that function to determine what connection to use > - and gradually add pre-cooked solutions. The advanced users can take > advantage of it right away, defining their custom shard logic. The > usual single-db Django apps won't even notice. We can then very > quietly and gradually build on it. > > Once we get into things like cross-database joins, we would need to > modify the ORM more to be aware that, but we could take this all one > step at a time, just as Malcolm recommended. > > Mike. > > Obviously this function could get very complicated for a heavily > sharded setup > > On Sep 10, 2:55 pm, ab <[EMAIL PROTECTED]> wrote: > > > For the api to accept a DSN, alias, or connection anywhere would add > > similar code in multiple places. I propose that the aliases are mapped > > into django.db.connections. For your example, you could use > > django.db.connections.archive. I also propose that you can either > > define a single database (as now) or multiple DATABASES (as you > > propose) and to define both or neither is an error. But anyways, how > > to name/specify a database is semi-bikesheddy and orthogonal to the > > issue of how to actually choose the database to be used, which is the > > more important one. Here's my take on that: > > > My biggest problem with Simon's original proposal is that the > > connection-choosing logic is too spread out. Sticking stuff on your > > Model classes makes sense when the code is "local to that model" -- > > like methods, metadata, or choosing a connection per-table -- but that > > doesn't make sense for a lot of multi-db setups. For complicated stuff > > like sharding, I think you'd want all the logic in the same place. > > > Counter-proposal: > > A *project-global* get_connection function, maybe in a location > > specified by settings. > > Input: the queryset, at least, and probably whatever else you'll > > likely want to use: the model class, tables joined with, > > fields_accessed?, etc. > > Output: a connection object > > > That would make it easier to write and maintain your multi-db setup > > and share logic across models. If you want control at the queryset- > > granularity, this could maybe result in a proposed_connection > > parameter to get_connection (and get_connection can obviously raise > > exceptions as it sees fit). This proposal also solves the problem of > > choosing a connection for contrib or 3rd-party applications. > > > Andrew > > > On Sep 10, 10:53 am, Simon Willison <[EMAIL PROTECTED]> wrote: > > > > For those who weren't at DjangoCon, here's the state of play with > > > regards to multi-db support: Django actually supports multiple > > > database connections right now: the Query class (in django/db/models/ > > > sql/query.py) accepts a connection argument to its constructor, and > > > the QuerySet class (django/db/models/query.py) can be passed an > > > optional Query instance - if you don't pass it one, it will create a > > > Query that uses the default django.db.connection. > > > > As a result, if you want to talk to a different connection you can do > > > it right now using a custom manager: > > > > class MyManager(Manager): > > > > def get_query_set(self): > > > query = sql.Query(self.model, my_custom_db_connection) > > > return QuerySet(self.model, query) > > > > As Malcolm described it, he's provided the plumbing,
Re: Proposal: user-friendly API for multi-database support
So, I'm still learning my way around the deeper parts of the codebase, but at first glance the "function pointed to from settings.py" approach seems best. This way, the connection management is completely opaque to the model. If that function isn't defined, it can just fall back to the default connection. This requires minimal changes to the base model (to start with, anyway), and gives the developer finegrained control over what queries go where - as fine grained as they want. We can then build on that, adding "shortcuts" for basic use cases, like defining a cluster of slaves to balance reads on etc. for more "run-of-the-mill" problems. A distinct advantage of this approach is that it can be built up very gradually. We can start with literally nothing - just a hook in the model class to call that function to determine what connection to use - and gradually add pre-cooked solutions. The advanced users can take advantage of it right away, defining their custom shard logic. The usual single-db Django apps won't even notice. We can then very quietly and gradually build on it. Once we get into things like cross-database joins, we would need to modify the ORM more to be aware that, but we could take this all one step at a time, just as Malcolm recommended. Mike. Obviously this function could get very complicated for a heavily sharded setup On Sep 10, 2:55 pm, ab <[EMAIL PROTECTED]> wrote: > For the api to accept a DSN, alias, or connection anywhere would add > similar code in multiple places. I propose that the aliases are mapped > into django.db.connections. For your example, you could use > django.db.connections.archive. I also propose that you can either > define a single database (as now) or multiple DATABASES (as you > propose) and to define both or neither is an error. But anyways, how > to name/specify a database is semi-bikesheddy and orthogonal to the > issue of how to actually choose the database to be used, which is the > more important one. Here's my take on that: > > My biggest problem with Simon's original proposal is that the > connection-choosing logic is too spread out. Sticking stuff on your > Model classes makes sense when the code is "local to that model" -- > like methods, metadata, or choosing a connection per-table -- but that > doesn't make sense for a lot of multi-db setups. For complicated stuff > like sharding, I think you'd want all the logic in the same place. > > Counter-proposal: > A *project-global* get_connection function, maybe in a location > specified by settings. > Input: the queryset, at least, and probably whatever else you'll > likely want to use: the model class, tables joined with, > fields_accessed?, etc. > Output: a connection object > > That would make it easier to write and maintain your multi-db setup > and share logic across models. If you want control at the queryset- > granularity, this could maybe result in a proposed_connection > parameter to get_connection (and get_connection can obviously raise > exceptions as it sees fit). This proposal also solves the problem of > choosing a connection for contrib or 3rd-party applications. > > Andrew > > On Sep 10, 10:53 am, Simon Willison <[EMAIL PROTECTED]> wrote: > > > For those who weren't at DjangoCon, here's the state of play with > > regards to multi-db support: Django actually supports multiple > > database connections right now: the Query class (in django/db/models/ > > sql/query.py) accepts a connection argument to its constructor, and > > the QuerySet class (django/db/models/query.py) can be passed an > > optional Query instance - if you don't pass it one, it will create a > > Query that uses the default django.db.connection. > > > As a result, if you want to talk to a different connection you can do > > it right now using a custom manager: > > > class MyManager(Manager): > > > def get_query_set(self): > > query = sql.Query(self.model, my_custom_db_connection) > > return QuerySet(self.model, query) > > > As Malcolm described it, he's provided the plumbing, now we need to > > provide the porcelain in the form of a powerful, user-friendly API to > > this stuff. Here's my first attempt at an API design. > > > Requirements > > > > > There are a number of important use-cases for multi-db support: > > > * Simple master-slave replication: SELECT queries are distributed > > between slaves, while UPDATE and DELETE statements are sent to > > the master. > > * Different Django applications live on different databases, e.g. > > a forum on one database while blog lives on another. > > * Moving data between different databases - it would be useful if > > you could do this using the ORM to help paper over the > > differences in SQL syntax. > > * Sharding: data in a single Django model is distributed across > > multiple databases depending on some kind of heuristic (e.g. by > > user ID, or with archived content moved to a different server) > > * Replication tricks, for
Re: Proposal: Day of Week Filter in ORM on Date / DateTime Fields
On Sep 30, 12:29 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I've been thinking through, with a couple of different people, how we > can support extra lookup types on fields and so I'm going to reserve > judgement on this particular implementation until I have some thoughts > in order on the latter subject. Maybe you'll convince another maintainer > in the interim, but it's probably a good start to get the patch up to > date and then drop it into the 1.1 features list, since running, tested > code is always a good start for assessing something. It'd be great to have some sort of drop-in architecture to allow new query types that can be defined perhaps by an installed application, rather than having to modify the Django distribution. That said, since such a beast doesn't currently exist, I've just updated my code to work on a current SVN checkout of Django. From my POV the only thing missing is testing on Oracle, although I appreciate that other viewpoints may see it wildly differently :) > If you're writing an API for talking to the data storage layer, pick a > value for the first day that is consistent at the Django level Don't > create extra problems for yourself here by inentionally letting > presentation information leak into the ORM layer. Good point - the code currently attached to the ticket will always force Sunday=1, Saturday=7. This happens regardless of the database backend in use. Thanks for your feedback Malcolm, I'll leave it here for the moment to see what comments other contributors may have. Regards, Ross --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Day of Week Filter in ORM on Date / DateTime Fields
On Mon, 2008-09-29 at 18:37 -0700, Ross Poulton wrote:
> When working with any calendar or event tracking information in Django
> it would be useful to be able to filter for items based on day of
> week:
>
> Event.objects.filter(event_date__week_day=1) # objects from any
> month/year/date, provided it's a Sunday
>
> will generate:
>
> SELECT ... WHERE EXTRACT('dow' FROM pub_date) = '1'; # Syntax
> varies on DB engine used.
>
> The most common use case for this is probably recurring events, so it
> won't be used by _everybody_ but it's a relatively simple change to
> implement.
>
> I've done most of the footwork and investigation for this, a patch is
> attached to ticket #7672 [1]. It hasn't actually been updated now
> since pre-1.0, so I'm cleaning it up now and should have a new version
> shortly. Between my patch & 1.0 were no major ORM changes that I'm
> aware of, so it'll be incidentals such as docs & tests that will need
> a real cleanup. AFAIK the code works on MySQL, Postgres & SQLite, and
> needs somebody to test on Oracle for it to be complete.
I'm personally a bit "meh" on this idea, although I can see it's useful
for some number of people > 1. There's no such thing as a "simple
change". I suspect the pros and cons pretty nicely balance each other
out.
I've been thinking through, with a couple of different people, how we
can support extra lookup types on fields and so I'm going to reserve
judgement on this particular implementation until I have some thoughts
in order on the latter subject. Maybe you'll convince another maintainer
in the interim, but it's probably a good start to get the patch up to
date and then drop it into the 1.1 features list, since running, tested
code is always a good start for assessing something.
>
> Any thoughts on this? The only real alternative is to drop to raw SQL
> in a calendar app - but if we can exploit functionality within the
> database to do it cleanly in the ORM, why not?
>
> The only potential pitfall I'm aware of is with weeks starting on
> different days, see ticket #1061 [2]. I'm not intimate with the
> details of that ticket so can't really comment on it at this stage.
If you're writing an API for talking to the data storage layer, pick a
value for the first day that is consistent at the Django level. People
handling localised dates with different start dates will have to do the
conversion before making it a filter. When Django adds support for that
kind of stuff, we might well end up with some utility functions if this
type of filter goes into the ORM. Don't create extra problems for
yourself here by inentionally letting presentation information leak into
the ORM layer.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Day of Week Filter in ORM on Date / DateTime Fields
My latest patch added to ticket # 7672 works against the latest SVN checkout (r9097). All it needs in my opinion is a decision on the best way to handle Oracle dates, and testing against Oracle. Ross --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: Day of Week Filter in ORM on Date / DateTime Fields
When working with any calendar or event tracking information in Django
it would be useful to be able to filter for items based on day of
week:
Event.objects.filter(event_date__week_day=1) # objects from any
month/year/date, provided it's a Sunday
will generate:
SELECT ... WHERE EXTRACT('dow' FROM pub_date) = '1'; # Syntax
varies on DB engine used.
The most common use case for this is probably recurring events, so it
won't be used by _everybody_ but it's a relatively simple change to
implement.
I've done most of the footwork and investigation for this, a patch is
attached to ticket #7672 [1]. It hasn't actually been updated now
since pre-1.0, so I'm cleaning it up now and should have a new version
shortly. Between my patch & 1.0 were no major ORM changes that I'm
aware of, so it'll be incidentals such as docs & tests that will need
a real cleanup. AFAIK the code works on MySQL, Postgres & SQLite, and
needs somebody to test on Oracle for it to be complete.
Any thoughts on this? The only real alternative is to drop to raw SQL
in a calendar app - but if we can exploit functionality within the
database to do it cleanly in the ORM, why not?
The only potential pitfall I'm aware of is with weeks starting on
different days, see ticket #1061 [2]. I'm not intimate with the
details of that ticket so can't really comment on it at this stage.
Ross
[1] http://code.djangoproject.com/ticket/7672
[2] http://code.djangoproject.com/ticket/1061
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: threading, caching, and the yield in query.py
On Mon, 2008-09-29 at 10:37 -0700, bo wrote: > > This little issue is really hard to replicate .. i've yet to find out > how to programatically do it because it certainly revolves around a > threading, object caching, and the Yield in Query.py (iteritems). > > I just wanted to post this here to see if anyone, with more experience > then i, knows howto replicate this in a test case world. > > On to the description > > The set up:: Apache 2.2.6 + Linux + Threaded (_not_ forked) + > mod_python + Django 1.X > > Suppose i have a 2 level caching object, that basically overloads the > function to store/get the object(s) from a Memcached overlord cache > (say 60 second expire), and 'local' cache (with a 1-2 second expire > time) .. the basic function is to keep a highly requested object > _per_ HTTP request local in ram w/o having to go back to the Memcached > cache. > > because of various iterators basing themselves off of "yield" > statements in db/models/query.py. Should 2 threads access the same > Local RAM cache object and try to iterate (yes the READS from the > cache are read/write locked, but this issue appears after the read > lock is released and the object is begin used), the ususal "Value > Error: Generator already running" exception is thrown. > > File "mything/models.py", line 1072, in _set_data > for p in self.data: > File "/usr/lib/python2.5/site-packages/django/db/models/query.py", > line 179, in _result_iter > self._fill_cache() > File "/usr/lib/python2.5/site-packages/django/db/models/query.py", > line 612, in _fill_cache > self._result_cache.append(self._iter.next()) > ValueError: generator already executing > > So, i'm aware this may not be a bug. But my own ignorance for not > doing something right. > > This does not happen very often in the servers i am running (about 10 > times a day on a 100k+ Django views/per day) which is why its really > hard to track down I don't understand from your description what you're actually doing, but it sounds a lot like you're trying to read from the same QuerySet in multiple threads whilst it's still retrieving results from the database cursor. Don't do that. Firstly, database cursor result sets aren't necesarily safe to be shared across threads. QuerySet and Query objects probably are once the result set is populated, since every non-trivial operation on them creates a copy and parallel iteration is supported, but that's more by accident than design, since it's not worth the extra overhead: if you want to share QuerySets via caching, they contain the results (the result_cache is already fully primed). Nothing in Django will cache a connection to the database or a cursor result set, so can you break down your problem a bit more to describe where the simultaneous access is happing. You say "the usual ValueError", but I have never seen that raised by anything in Django. So I'm wondering if you're doing something fairly unusual here. That particular block of code is *designed* to be used in parallel iterators in the same thread, so it's safe in that respect. But if you're sharing a partially-read database cursor iterator across multiple threads, it might be a case of it breaks you get to keep all the pieces. I can't see why that would be necessary (if you want to cache the results, just cache the queryset and it will cache the results; if you want to cache the query, cache queryset.query and it will just cache the query; both of those cases are designed in and documented). 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
On Mon, 2008-09-29 at 03:25 -0700, Richard Davies wrote: [...] > So, do we agree that it makes sense for me to take the current 3460 > patch and complete it in the manner which I described in > http://groups.google.com/group/django-developers/msg/48500109ac5e514d > ? I'd be amazed (and fairly disappointed) if two copies of the code in transaction.py was required. I'm fairly sure it can all be done by examining the current transaction handling state inside existing methods. But give it a shot however you like. As usual with patches, no guarantees apply beforehand as to whether they'll be committed or not because we often/usually have to look at an implementation before knowing if it's going to work long-term. However, if I was doing this (and if no reasonable alternative pops up in the next couple of months I probably will), I'd be trying very hard to avoid any code duplication at all. I realise it sounds fuzzy to say "my intuition says", but it looks like it should be possible to do checks for whether we're in auto-commit mode or not and have all the existing calls just behave normally -- including allowing manual transaction starts regardless of the mode. The implementation here will probably turn out to be easy. The design will be the hard bit. Regards, Malcolm > I'd particularly like Malcolm to confirm if my description there > matches his discussion with Collin. > > If we're agreed, then I'll take over ownership of that ticket from > Collin (unless you want to do it, Collin?), and I'll add 'optional > native autocommit' to the Django 1.1 features list. > > Cheers, > > Richard. > > > > One technical point: > > When I started writing in this thread, I hadn't appreciated that > rollback() and rollback_unless_managed() are used by Django outside > explicit user-started transaction management in order to attempt to > keep things consistent after failures. How do people think that we > should handle these when 'native autocommit' is on? The options seem > to be: > a) Make them no-ops and accept the failures > b) Work out which points they roll back to, and add explicit 'BEGINs' > at those points > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ManyToManyField with raw_id_admin
After miserably failing at making it possible to use a field with 10k choices, I've decided to take a new approach in the admin. Right now I'm writing up a widget which would take the m2m field (for raw_admin_fields) and output it just as it would a foreign key, except one input per line. This sounds like something that could be very useful in trunk, and I was curious as to the stance on this, or if it's somehow already done? :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Soliciting Feedback on SelectTimeWidget
Hi All, I posted this earlier in Django-users, but then I thought this might be a better place. I've started working on a SelectTimeWidget that is very similar to the SelectDateWidget in django.forms.extras. http://dpaste.com/hold/81196/ I'm also pondering the creation of a SelectDateTimeWidget, so that we have widgets that directly correspond to the DateField, TimeField, and DateTimeField classes. (not to mention datetime.time, datetime.date, datetime.datetime) This is my first look at Django's internals, so any (constructive) criticism is welcome! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: database clustering/sharding automation
On Mon, Sep 29, 2008 at 1:22 PM, mihasya <[EMAIL PROTECTED]> wrote: > Hey, is anybody actually tackling the database scale stuff Cal "joked" > about in his keynote? I'd like to work on it, but don't want to spin > my wheels if the core team is already working on it. If you'll search the archives of this list, you'll see there's an active thread with a lot of discussion on these issues. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
database clustering/sharding automation
Hey, is anybody actually tackling the database scale stuff Cal "joked" about in his keynote? I'd like to work on it, but don't want to spin my wheels if the core team is already working on it. Mike. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
Brian Beck wrote: > I think your model_field helper being built-in (short for > x._meta.get_field(y).formfield(**params), which is not very pretty) > would be the best solution here. In my experience, customizing just > the widget for a model field is just as common as changing just the > label, just the help text, or just the 'required' status. Using your > helper one could override any number of these, the rest being taken > from the defaults. May be... I just don't like how it looks. Apart from repeating model name for each field and field's own name twice it is not as readable as a couple of params in Meta that clearly show in what the form is different from default state. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
threading, caching, and the yield in query.py
This little issue is really hard to replicate .. i've yet to find out how to programatically do it because it certainly revolves around a threading, object caching, and the Yield in Query.py (iteritems). I just wanted to post this here to see if anyone, with more experience then i, knows howto replicate this in a test case world. On to the description The set up:: Apache 2.2.6 + Linux + Threaded (_not_ forked) + mod_python + Django 1.X Suppose i have a 2 level caching object, that basically overloads the function to store/get the object(s) from a Memcached overlord cache (say 60 second expire), and 'local' cache (with a 1-2 second expire time) .. the basic function is to keep a highly requested object _per_ HTTP request local in ram w/o having to go back to the Memcached cache. because of various iterators basing themselves off of "yield" statements in db/models/query.py. Should 2 threads access the same Local RAM cache object and try to iterate (yes the READS from the cache are read/write locked, but this issue appears after the read lock is released and the object is begin used), the ususal "Value Error: Generator already running" exception is thrown. File "mything/models.py", line 1072, in _set_data for p in self.data: File "/usr/lib/python2.5/site-packages/django/db/models/query.py", line 179, in _result_iter self._fill_cache() File "/usr/lib/python2.5/site-packages/django/db/models/query.py", line 612, in _fill_cache self._result_cache.append(self._iter.next()) ValueError: generator already executing So, i'm aware this may not be a bug. But my own ignorance for not doing something right. This does not happen very often in the servers i am running (about 10 times a day on a 100k+ Django views/per day) which is why its really hard to track down --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ANN: 1.0.X branch created; trunk is open for features
Hi folks -- I've created the 1.0.X branch (http://code.djangoproject.com/svn/django/branches/releases/1.0.X), which means the trunk is now open for features. Please read http://docs.djangoproject.com/en/dev/internals/release-process/ for more information about what this branch is. For the record, here are the important bits: - Commits must be cleanly separated between bug fixes and feature additions. - Bug fixes must be applied both to trunk and to the 1.0.X branch. - Whenever possible, improvements to documentation should do the same. Karen Tracey is the 1.0.X release maintainer; she'll be keeping an eye out to make sure that this happens correctly. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
SmileyChris wrote: > I do feel like it leads to slippery slope though. LikeMichael said, > "why stop at widgets?" I often need to change labels and help text > too. Full customization already can be done by specifying fields directly in a form class. In my experience widgets are just very common case. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
On Sep 29, 11:40 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
>
> > Why not do something like this:
>
> > class MyForm(forms.ModelForm):
> > class Meta:
> > fields = {
> > 'text': forms.CharField(widget=forms.Textarea(), ...),
> > 'other_field': None,
> > }
>
> This syntax would not be completely DRY. If, for example, the model's
> 'text' field was optional (blank=True), you would need to explicitly
> specify the form field as optional (required=False) as well:
>
> ...
> 'text': forms.CharField(widget=forms.Textarea(),
> required=False...),
> ...
>
> By having a separate 'widgets' option you could modify the widgets
> independently from anything else. Not only is that DRY but also that
> would prevent some potential mistakes.
Also, you can already completely override a field like follows:
class MyForm(forms.ModelForm):
title = forms.CharField(widget=forms.Textarea(), ...)
class Meta:
model = Article
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
> Why not do something like this:
>
> class MyForm(forms.ModelForm):
> class Meta:
> fields = {
> 'text': forms.CharField(widget=forms.Textarea(), ...),
> 'other_field': None,
> }
This syntax would not be completely DRY. If, for example, the model's
'text' field was optional (blank=True), you would need to explicitly
specify the form field as optional (required=False) as well:
...
'text': forms.CharField(widget=forms.Textarea(),
required=False...),
...
By having a separate 'widgets' option you could modify the widgets
independently from anything else. Not only is that DRY but also that
would prevent some potential mistakes.
> On Sep 29, 11:07 am, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > Bah, it was just prototype code but point taken ;)
>
> > I do feel like it leads to slippery slope though. LikeMichael said,
> > "why stop at widgets?" I often need to change labels and help text
> > too.
>
> > On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> > > SmileyChris wrote:
> > > > I've always just done this by doing:
>
> > > > MyForm(ModelForm)
> > > > model = MyModel
> > > > def __init__(self, *args, **kwargs):
> > > > self.fields['name'].widget = Textarea() # or whatever
>
> > > You've forgot to call `super` :-). I know that it's only an example but
> > > it adds another line and also shows that such things can easily be
> > > forgotten in real code.
>
> > > > Do we really need another way of doing this? Or am I overlooking
> > > > something that this new method introduces?
>
> > > I've addressed this exact thing my first email on subject, so quoting
> > > myself:
>
> > > > Here the problem is that it has enough boilerplate code to be, shall we
> > > > say, not beautiful. And also it defeats nice declarative nature of a
> > > > ModelForm.
>
> > > So, yes, it's not the end of the world but it's the same convenience as
> > > `fields` or `exclude` that all could be simulated in __init__.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
I understand the motivation for this, and support the idea, but I
think the implementation is a little repetitive:
class MyForm(forms.ModelForm):
class Meta:
fields = # LIST OF FIELDS
widgets = # DICT OF FIELD NAMES : WIDGETS
Why not do something like this:
class MyForm(forms.ModelForm):
class Meta:
fields = {
'text': forms.CharField(widget=forms.Textarea(), ...),
'other_field': None,
}
Where the 'None' indicates "do the default". This way you could
completely redefine the behaviour of the model form. Putting in a list
or tuple would just do what it's always done.
Regards,
Zack
On Sep 29, 11:07 am, SmileyChris <[EMAIL PROTECTED]> wrote:
> Bah, it was just prototype code but point taken ;)
>
> I do feel like it leads to slippery slope though. LikeMichael said,
> "why stop at widgets?" I often need to change labels and help text
> too.
>
> On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> > SmileyChris wrote:
> > > I've always just done this by doing:
>
> > > MyForm(ModelForm)
> > > model = MyModel
> > > def __init__(self, *args, **kwargs):
> > > self.fields['name'].widget = Textarea() # or whatever
>
> > You've forgot to call `super` :-). I know that it's only an example but
> > it adds another line and also shows that such things can easily be
> > forgotten in real code.
>
> > > Do we really need another way of doing this? Or am I overlooking
> > > something that this new method introduces?
>
> > I've addressed this exact thing my first email on subject, so quoting
> > myself:
>
> > > Here the problem is that it has enough boilerplate code to be, shall we
> > > say, not beautiful. And also it defeats nice declarative nature of a
> > > ModelForm.
>
> > So, yes, it's not the end of the world but it's the same convenience as
> > `fields` or `exclude` that all could be simulated in __init__.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
I'm going to make one final post in this thread, since we didn't quite reach a conclusion. Malcolm Tredinnick wrote: > As I mentioned to Collin at the code sprint in Portland, I think it'd be > a good idea to make sure we expose the ability to turn on auto-commit, > but I don't really like making it the default. In any case, providing > the ability that's can be controlled via, for example, a setting is > certainly the first step here. That's pretty independent of the whatever > the default might end up being. That's really the improvement needed to > #3460 at the moment -- separating adding functionality from changing the > default. Richard Davies wrote: > I think that we should try to write a patch which a) makes 'native > autocommit' a configuration option as suggested, and b) supports > transactions on top of the 'native autocommit' connection when explicitly > requested (the current 3460 patch doesn't, so parts of the test suite > currently fail when it is applied). Metajack wrote: > +1 from me So, do we agree that it makes sense for me to take the current 3460 patch and complete it in the manner which I described in http://groups.google.com/group/django-developers/msg/48500109ac5e514d ? I'd particularly like Malcolm to confirm if my description there matches his discussion with Collin. If we're agreed, then I'll take over ownership of that ticket from Collin (unless you want to do it, Collin?), and I'll add 'optional native autocommit' to the Django 1.1 features list. Cheers, Richard. One technical point: When I started writing in this thread, I hadn't appreciated that rollback() and rollback_unless_managed() are used by Django outside explicit user-started transaction management in order to attempt to keep things consistent after failures. How do people think that we should handle these when 'native autocommit' is on? The options seem to be: a) Make them no-ops and accept the failures b) Work out which points they roll back to, and add explicit 'BEGINs' at those points --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
Bah, it was just prototype code but point taken ;) I do feel like it leads to slippery slope though. LikeMichael said, "why stop at widgets?" I often need to change labels and help text too. On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: > > I've always just done this by doing: > > > MyForm(ModelForm) > > model = MyModel > > def __init__(self, *args, **kwargs): > > self.fields['name'].widget = Textarea() # or whatever > > You've forgot to call `super` :-). I know that it's only an example but > it adds another line and also shows that such things can easily be > forgotten in real code. > > > Do we really need another way of doing this? Or am I overlooking > > something that this new method introduces? > > I've addressed this exact thing my first email on subject, so quoting > myself: > > > Here the problem is that it has enough boilerplate code to be, shall we > > say, not beautiful. And also it defeats nice declarative nature of a > > ModelForm. > > So, yes, it's not the end of the world but it's the same convenience as > `fields` or `exclude` that all could be simulated in __init__. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
SmileyChris wrote: > I've always just done this by doing: > > MyForm(ModelForm) > model = MyModel > def __init__(self, *args, **kwargs): > self.fields['name'].widget = Textarea() # or whatever You've forgot to call `super` :-). I know that it's only an example but it adds another line and also shows that such things can easily be forgotten in real code. > Do we really need another way of doing this? Or am I overlooking > something that this new method introduces? I've addressed this exact thing my first email on subject, so quoting myself: > Here the problem is that it has enough boilerplate code to be, shall we > say, not beautiful. And also it defeats nice declarative nature of a > ModelForm. So, yes, it's not the end of the world but it's the same convenience as `fields` or `exclude` that all could be simulated in __init__. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unique_for_ fields
On Sep 28, 5:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Short version: model-aware validation is being worked on. We didn't get > it finished for 1.0, but it's still ongoing work. Great! Judging by the activity this is tracked in #6845 so I included a note and a reference in the ticket (and will wait instead of trying to fix it now). -rob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
