Re: Proposal: make templatetag loading magic a little more invisible
This is another case* where using something like setuptools entry points for loading 3rd-party plugins would make all of these problems go away. Entry points specifically would impose an additional burder on app writers, though, because they'd have to register their tag libraries explicitly in setup.py. JP * ref my fevered rantings here: http://groups.google.com/group/django-developers/browse_frm/thread/af002765821b5e57 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Python Web Framework
I agree with basically everything in that post. Models are too tightly tied to their admin representation. It is too hard to use another ORM with django's contrib apps, and fairly pointless to use one if you can't do that. The admin app itself could benefit greatly from another rewrite, to simplify and open it up. The template language is fantastic for designers and less so for programmers. Enforcing the loading of settings at import time is ... not a choice I would have made, let's just say. But most if not all of those problems are fixable. Django is just at the beginning of its life as an open source project. It's good enough for serious, professional work now and it's getting better all the time. I think it's going to keep getting better as it attracts more users with more good ideas -- so long as the core developers' bandwidth holds up. :) JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Python Web Framework
> Anybody have ideas on how to change the settings framework not to be > required at load time? I'm not sure how acceptable this would be, but what springs to mind immediately is refactoring LazySettings and Settings to push all of the settings-loading logic into the Settings used, and using a Settings subclass by default that is happy to just use whatever the default settings are, and only raises an exception if you try to access a setting that's not in the defaults. Then in environments (like the various http handlers) that want to enforce the settings module being defined or configure() being executed, we can install a Settings instance in settings._target that behaves appropriately for those environments (eg, is thread-local and resets on request start in WSGI environments, for Paste friendliness). JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
James Bennett wrote: > On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote: > > SA provides: > > * connection pooling - since you asked about it, I'll quote from the SA > > docs: > > This is why I said "what comes to mind when I think 'database > connection pooling' isn't something I think belongs in Django." > > Maintaining in-process connection pools in the framework doesn't, in > my experience, provide enough benefit to justify the hassle. I'd > rather talk to something like pg_pool which maintains an external > connection pool. I think the problem here is competing definitions of the term 'connection pool'. You're using 'connection pool' to mean a connection that may be transparently directed to one of N databases (say where records 1-100 are on database machine A and 101-20 are on database machine B, or you're writing to A and reading from A and B), I think. And I think that Karl and Christopher are using 'connection pool' to mean a collection of N persistent connections to the SAME database, where threads in a web app can check out and use connections from the pool, so that each thread need not make and hold its own connection. So I agree, django's ORM doesn't need pools (definition 1), but it does need pools (definition 2) to help it scale better in some environments and to reduce request startup time. Hopefully the words I've put in your mouths are the right ones. :) JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
> > So I agree, django's ORM doesn't need pools (definition 1), but it does > > need pools (definition 2) to help it scale better in some environments > > and to reduce request startup time. > > I'm going to stick with thinking we don't need them in either case; > the gain of simplicity and loose coupling in your overall stack is, to > me, a killer feature. I still think there is some kind of definitional crosstalk here, because I don't see what's less simple or more tightly coupled about: from django import db # connection is checked out from pool of persistent connections connection = db.connection vs. from django import db # connection is a module-level global initialized on import connection = db.connection The kinds of pools I think would be helpful aren't things like pg_pool, they are more analagous to a thread pool. Like the common use case where a defined number of worker threads consume jobs from a queue. In this case, a defined number of db connections are made at startup, and request handler threads check out a connection when they need one, rather than each thread connecting and disconnecting around every request. For a high-volume threaded server, that can be a life saver. And even for a low-volume server you can get rid of the overhead of making and breaking the connection on each request without the risk of a runaway googlebot starting 10 threads and beating your db server to a pulp. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
gabor wrote: > hmmm..so am i correct when i say, that in a non-multithreaded web-app > definition-2-pools are not needed/ do not help? Pretty much. The benefit really comes in multi-threaded environments where a new thread is being started for each request. When each of those threads makes its own db connection, you can see how a big traffic spike can be catastrophic -- there's no limit on the number of connections that might be made. With a limited pool of connections, you can at least choose to block or raise an exception when a connection isn't available, so your worst case scenario is a nice error or a slow response, not a dead db server. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Multi-db: Change DatabaseWrappers to no longer be local?
Looking back over the multi-db branch today, I realized that it seems to be duplicating the thread locality of connections. The connection management classes in multi-db django.db manage all connections as thread local, and the DatabaseWrapper classes in the backends are all subclasses of local. I may be missing something, but I think the latter locality can be safely removed in multi-db. DatabaseWrappers don't have to be local because each instance can only be accessed in a particular thread anyway. Since I had previously said multi-db was feature complete, I thought I should bring the change up here before comitting it. Let me know if you have any objections or can see that I am missing something. I'll commit the change within a couple of days if there are no objections, or sooner if anyone wants to try it now. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multi-db: Change DatabaseWrappers to no longer be local?
Ivan Sagalaev wrote: > JP wrote: > > Looking back over the multi-db branch today, I realized that it seems > > to be duplicating the thread locality of connections. The connection > > management classes in multi-db django.db manage all connections as > > thread local, and the DatabaseWrapper classes in the backends are all > > subclasses of local. > > > > I may be missing something, but I think the latter locality can be > > safely removed in multi-db. > > I didn't look how exactly multi-db branch manages connection so my > question may be dumb, sorry. If you intend remove the inheritance of > DatabaseWrapper from locals does it mean that when using single DB > DatabaseWrappers will be shared between threads? Not a dumb question at all. I'll try to explain better by contrasting how multi-db handles connections with how connections are kept thread local in trunk. In trunk, django.db.connection is a DatabaseWrapper instance from some backend. DatabaseWrappers all subclass local, so their attributes are thread local, including the self.connection attribute that is the actual db connection. When you try to get a cursor for the first time in a thread, a connection is made based on the current settings and stored in the local attribute. In multi-db, all connections (including the default that you can access as django.db.connection) are managed through a LazyConnectionManager instance, which keeps a thread-local map of connection name to DatabaseWrapper, and is generally accessed through django.db.connections, like: from django.db import connections, _default, connection foo = connections['foo'] connection is connections[_default] # True When a connection is first accessed in a thread, the connection is established based on the appropriate settings (either defaults or a named connection in OTHER_DATABASES) and a DatabaseWrapper is cached in thread local storage. django.db.connection is a lazy proxy that looks up connections[_default] when accessed for the first time in a thread, and caches the result of that call in another local (for efficiency, otherwise we'd be executing a lambda: every time we touched the connection, which would be bad). So each individual connection instance doesn't need to be a local anymore, because it can only be accessed by a lookup into a local, no matter how you get at it. > > DatabaseWrappers don't have to be local > > because each instance can only be accessed in a particular thread > > anyway. > > I don't exactly understand this bit also. Does it mean that each thread > gets its own instance or that threads can access some (shared) instance? Each thread gets its own DatabaseWrapper instance, rather than one DatabaseWrapper (with local attributes) being shared among all threads. Does that make things more clear? JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multi-db: Change DatabaseWrappers to no longer be local?
Ivan Sagalaev wrote: > JP wrote: > > Not a dumb question at all. I'll try to explain better by contrasting > > how multi-db handles connections with how connections are kept thread > > local in trunk. > > BTW, I happen to know how it works now since I was among those who was > trying to solve threading issues before Eugene Lazutkin's universal > patch with DatabaseWrapper inherited from local(). Ah! Sorry, I didn't know the history. I'm sort of new in town. :) > I'm asking because I'm worried if something new could break something > working :-) Me too! > This explains it all, thank you! I now actually found this code in > db/backends/__init__.py and from the look of it I agree that inheriting > DatabaseWrapper from local() is no longer needed. Good. So that's one vote for checking in the change to the branch. Anyone else have any thoughts/objections/questions/whatever? Thanks! JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
Dan Watson wrote: > Ideally, it seems django should offer simple connection pooling with 2 > options: number of connections and an on/off switch. That would satisfy > the needs of some/most, and for those that need something more robust, > look into an external pooler. Thinking this over a bit more, I think the best solution may be to just provide a hook in core that pool-wanters can use to install pooled connection management. Conveniently :), in the multi-db branch, connections are managed through a connection manager, so there's the hook for those who want to use pooling. The default manager creates one connection per thread, but making one that uses a robust pooling mechanism would be as simple as: 1. stealing sqlalchemy's pool code (MIT licensed) 2. plugging it into a class that acts like django.db.LazyConnectionManager but checks out connections from a pool; the tough part will be hooking up connection.close() to release the connection back into the pool 3. from django import db; db.connections = YourPoolingClass() So in multi-db at least it's doable without too much hackery, and you can plug in whatever kind of pooling you need. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
I agree and disgree. :) I like James Bennetts's example a lot, but I'd like it more if the form class were ModelForm, descending from a more general Form class that would look much like the base Manipulator class of today. I'm afraid that I find the idea in Brantley Harris's proposal of raising a Form as an exception as a form of flow control really counter-intuitive. Apologies and it's just my opinion of course, but it has a sort of "too clever" feel to me. Also, exceptions are very expensive, and I don't see the practical benefits of that usage pattern over something like: form = Poll.CreateForm(request) errors = form.validate() if errors: ... else: ... Last up, a question for James. In your example you have exclude_fields and extra_fields. What if I want to bind a different form field type to a model field? What would the synax be for that? Something like: class CrazyArticleForm(ArticleAddForm): override_fields = ( myapp.CrazyField(field_name='title', model_field='title', ) Maybe? (I don't like 'override' there but I'm not sure what else to call it.) And in service of that sort of thing, I think at the input conversion phase, the form should delegate to each field to pull its data out of the request, since some fields may be singular in concept but spawn multiple html elements. That brings up a related question: can one form field bind to multiple model fields? (I'm thinking of file upload, where you get can back a filename and a mime type and the file contents). JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
James Bennett wrote: > On 8/24/06, JP <[EMAIL PROTECTED]> wrote: > > I like James Bennetts's example a lot, but I'd like it more if the form > > class were ModelForm, descending from a more general Form class that > > would look much like the base Manipulator class of today. > > I think you're confusing me with someone else... Sorry! I mixed up Joseph, who was quoted in Adrian's email, with your first reply to the message with the quote. Apologies to James and Joseph for the misattribution. I still like the ideas. :) > > I'm afraid that I find the idea in Brantley Harris's proposal of > > raising a Form as an exception as a form of flow control really > > counter-intuitive. Apologies and it's just my opinion of course, but it > > has a sort of "too clever" feel to me. Also, exceptions are very > > expensive, and I don't see the practical benefits of that usage pattern > > over something like: > > The benefit, as I see it, is that it's much simpler and much more > descriptive of what's actually going on; you've got some data, you're > trying to save an object from it. Which, logically, translates into a > try/except block around the form's 'save' method; that makes the code > crystal-clear on what you're actually trying to do. All I can say is that I don't see it that way. For me, raising the form as an exception (or an exception referencing the form) seems unnatural and unintuitive, and much less explicit, readable, etc, than just dealing with the flow of form validation and saving in the same way that Manipulators do now. And it ignores the many uses of forms that don't involve binding a form to single model that validates and saves the form input. I don't think that the view-manipulator interaction is broken, and I think it can be easily adapted to handle model-driven validation and saving, as in Joseph's sample code. So count me as -1 on using exceptions for form processing control, for whatever that's worth. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
This is great news! One question comes to mind first, because I am nothing if not self-absorbed. :) I wonder how much of the multi-db branch I have been working on will be made irrelevant by this. Any thoughts on how the sqlalchemy backend might support connecting different models to different engines? I'd be more than happy to suggest parts of multi-db to steal or adapt, or help with the stealing and adapting, if you're planning to include something like per-model engines in the implementation. More questions: Are you planning on building something like ActiveMapper, or using ActiveMapper, or rolling up a whole new ORM layer on top of the sqlalchemy core? If the last, I have some play-around code (from sqlalchemy around 0.1, though) that I will happily donate in case there is anything stealable or adaptable or so-horrifying-you-know-never-to-repeat-it in there. Great news. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
Robin Munn wrote:
> On 8/30/06, JP <[EMAIL PROTECTED]> wrote:
> >
> > This is great news!
> >
> > One question comes to mind first, because I am nothing if not
> > self-absorbed. :) I wonder how much of the multi-db branch I have been
> > working on will be made irrelevant by this. Any thoughts on how the
> > sqlalchemy backend might support connecting different models to
> > different engines? I'd be more than happy to suggest parts of multi-db
> > to steal or adapt, or help with the stealing and adapting, if you're
> > planning to include something like per-model engines in the
> > implementation.
>
> SQLAlchemy already has a DynamicMetaData object that can connect model
> objects to different database engines; I currently plan to use that.
> I'll definitely take a look at the multi-db code and would welcome any
> help you might want to offer.
That makes sense. The tricky part will be assigning different groups of
tables to different DynamicMetaData instances. For instance, say you
have an application that has to connect to two different legacy
databases, one for ... uh ... zoo animals and the other, plants in a
botantic garden. The multi-db branch handles this via a setting, like:
OTHER_DATABASES = {
'zoo': { 'DATABASE_ENGINE': ..,
'DATABASE_NAME': 'legacy_zoo',
'MODELS': [ 'zoo' ] # this is an app_label
},
'botany': { 'DATABASE_ENGINE': ...,
'DATABASE_NAME': 'legacy_plants',
'MODELS': ['plants']
}}
And then mediates database access through a property on each model's
default manager. The particular config syntax is secondary to that --
the important change is that all of a model's db access goes through a
property (however indirectly) of the model, and not a single global
connection.
> Basically, don't stop work on multi-db just because I'm starting this
> branch. I might hit a brick wall and not be able to complete it, or I
> might get hit by a bus tomorrow, or whatever -- you never know what's
> going to happen. I'd welcome any ideas or code you'd like to share,
> though.
Multi-db is pretty well done, aside from the never-ending task of
merging in trunk (which just got a whole lot harder as of r3661,
unfortunately). Many of the changes in there don't really apply, since
they are pretty specific to the django stock ORM. But there are at
least three that do, I think: moving the schema manipulation sql out of
django.core.management (extra challenging to preserve the nice terminal
colors in this case), adding the Model.objects.db property for access
to the db metadata for a model, and adding methods to Manager for
manipulating the schema of the attached model (create table, load
initial data, etc).
> I like "borrowing" from other
> people's work whenever I can, it means less work for me. :-) And
> that's what open-source development is all about, isn't it?
Indeed. Laziness is a virtue, someone once said. :) I managed to clean
up my old experiment enough that the tests pass under sqlalchemy 0.2.7.
You can grab a copy here:
http://somethingaboutorange.com/mrl/projects/models.tgz
The one thing I'd advocate stealing is making the model properties
descriptors that delegate to the columns of the sqlalchemy table (or
properties of the mapper). This allows a really nice query syntax,
like: Animal.objects.filter(Environment.last_cleaned < '2001-01-01'),
which I think is a lot better than (say)
Animal.objects.filter(Environment._meta.c.last_cleaned ... ) and
provides a natural place to put and access column metadata.
JP
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
> Then when you need to get at the > SQLAlchemy Table object, you'd do something like > Story._sa_table.some_method(). How about `Story._meta.table` or `Story._meta.c` or .columns or something, to avoid littering the model's namespace with more properties? JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
Jay Parlar wrote: > On 8/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > The goal is that this will have *zero* effect on existing queries. The > > Django query syntax will remain exactly the same, and the database API > > will stay the same. The only difference is that the SQLAlchemy backend > > will have *extra* functionality -- namely, that people will be able to > > fall into SQLAlchemy syntax if they want to. > > > > A question then: Once the SQLAlchemy stuff is in and solid, will there > be any reason *not* to use it? The Django query syntax is a great way to map a flattened dict to a query. A flattened dict like, say, GET or POST data. ;) JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
There I go, answering the wrong question... I should learn not to post after 10 pm, too many brain cells are asleep and the remainder can't handle typing and thinking at the same time. The reason not to use it I guess would be that you already have a working app and you don't need it. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Initial data hooks: management.install vs. management.syncdb
Ned Batchelder wrote: > I've also tried Jason's nose-django plugin, and it uses > management.install(app) to create the test database. This doesn't fire > a signal I can hook, so I wasn't able to create my initial data. Now that syncdb can be run non-interactively, I can switch the plugin over to calling that instead. It will take some time, however, because I need to figure out how to do that and use the new create/drop test db functions from djagnoo.test.utils when they are available without breaking the plugin for people who aren't tracking svn trunk. I should also mention that the plugin's home is now on Google code: http://code.google.com/p/nose-django/ JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Initial data hooks: management.install vs. management.syncdb
Russell Keith-Magee wrote: > On 9/5/06, JP <[EMAIL PROTECTED]> wrote: > > > > > > Now that syncdb can be run non-interactively, I can switch the plugin > > over to calling that instead. It will take some time, however, because > > I need to figure out how to do that and use the new create/drop test db > > functions from djagnoo.test.utils when they are available without > > breaking the plugin for people who aren't tracking svn trunk. > > > Glad to see that the new testing pieces are useful to you. If there is > anything we can do that will make integrating nose-django (or any other > external testing system for that matter) easier, let me know. I think the new testing stuff is great. Broke the heck out of my tests in the multi-db branch, but they're better now for having been broken. :) The only thing I can think of that would ease things for nose users would be to pass to the runner function whatever parts of sys.argv manage.py didn't consume, but I think that would be pretty tough to do with OptionParser, if it's even possible. Now I just need to find some time in between keeping multi-db merged and finishing nose's next release and making money and moving house to bring the nose-django plugin up-to-date to take advantage of the cool new stuff you added. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: App portability
You don't need to physically move an app from project to project to use the app in different projects. An app is just a python package. Say you have app 'foo' from project 'bar' and you want to use it in a new project, 'baz'. Install bar somewhere in your python path and then add bar.foo to the INSTALLED_APPS in baz and do whatever you want to do to hook up the urls from bar.foo under the desired prefix in baz. Just like using the django admin app. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Custom default managers interfere with delete operations
> Consider a weblog app with an Entry model and a Category model: > > * An Entry can be either "live" or "draft". > * There's a many-to-many relation between Entry and Category. [snip (paraphrased) altering the default manager breaks admin, but it's necessary to change how related fields do their lookups] > It'd be awfully nice not to end up in those sorts of "no-win" situations... Would it make any sense to allow relations to specify the manager they should use? For instance: class Category(models.Model): # ... entries = ManyToManyField(Entry, manager='live_entries') Or rework relations to allow relations to other *managers* instead of other *models*: class Category(models.Model): # ... all_entries = ManyToManyField(Entry.objects) entries = ManyToManyField(Entry.live_entries) SQLAlchemy does something similar to the 2nd example, in that relations are related to mappers not mapped classes. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
> class Form(object):
> fields = {} # This gets filled with field names and data types.
> def bind(self, **kwargs):
> "Returns a BoundForm instance for the given kwargs."
> return BoundForm(self, kwargs)
What's the rationale for using **kwargs instead of a single data
parameter? I think there are two big advantages to a single parameter
vs. kwargs: first, there are legal form field names that aren't legal
python identifiers, and second, it lets you use anything dict-like as a
form data source -- with the natural next step of a ModelForm that
takes a model instance as its bind parameter.
Otherwise, I think this is excellent, and Joseph's extensions to the
proposal also make a lot of sense. And +1 to the suggestions that
there's no need for a separate BoundForm class.
JP
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Russell Keith-Magee wrote:
> +1 to providing the ability to select a widget at the template level,
> but -1 to requiring .as_text for the default case.
What if widgets could act as filters? I think using filter syntax for
setting the widget for a field in the template would be pretty
natural::
{{ form.field }}
draws the default widget for the field type, but if you want to use
SomeOtherWidget, you can do::
{{ form.field|SomeOtherWidget }}
The tough part would be handling things on the POST side when
SomeOtherWidget is a collection of html fields that need to be
processed into one value, or something like a tags field that renders
as comma-separated text but should be processed as a list. For that
case I think you'd have to set the widget at form definition time,
otherwise you'd have mo way to know what widget's to_python method to
call to convert the input.
JP
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Serious problems with the way Django handles file uploads
Hello everyone. I started using Django about a week ago. I have a particular app which more or less accepts CSV files, Excel files, DBase files, and whatever else, takes the uploaded file, converts it to a tab-delimited format, and then does statistical work over it. Originally this application was written in PHP by someone else. I've since taken it and rewrote it in Rails. Rails didn't have good libraries (I had to call out to Python programs anyway), and it was slow, so I rewrote it in Python, in the Pylons web framework. As I said, about a week ago I started using Django, and I more or less directly converted this app from Pylons to Django. Pretty much all the web app itself does is display a form to upload the file, it uploads the file, and then passes if off to an outside Python library which does the conversion to tab. Once that is done, the framework (in this case a Django view function) takes control again and does the statistical work over the tab-delimited file. The code more or less for the Pylons and Django versions is identical. There are obviously small changes here and there to fit each framework, but the controller or view code has changed very little. Monday I got the entire app converted over to Django. I uploaded my first file, a DBase file, and immediately noticed that it was taking *forever*. After 24 seconds, I finally got my stats page. This same process takes 3 seconds in Pylons. Something definitely wasn't right here - my Django app was actually slower than both my Rails and the PHP app. So I started doing some tests to isolate the problem. I brought the issue up in #django on freenode IRC, and someone immediately suggested that the problem might be the dev server. Know that the dev server very well could be at fault, I took a little script and got my Django app running on the exact same Paste WSGI server that my Pylons app was running on. Again, it took 24 seconds for it to run this 6 MB file. Continuing on this testing this morning, I realized that a very good way to test out exactly where bottleneck existed was to cut out the uploading process alltogether - if the process finished very quickly on a file that was already uploaded to the local filesystem, then the problem existed within how Django's actual upload process. Sure enough, when I had the process run on an already-uploaded file, the process took 3 seconds. So uploading the file was taking 21 out of 24 seconds. Again I brough this up in the IRC chat. Someone told me that nobody was going to take my serious because I wasn't running Django the 'preferred' way, ie, on mod_python/Apache. I really didn't think this was the limiting factor, but I installed Apache and mod_python and got it all setup anyway. Again, it took 24 seconds for this file to upload and process. That was 8x as long as my Pylons app running on its dinky little WSGI Python server. At this point I was able to narrow down the issue: * it had to do with Django's upload process * it was an equal problem on any server, whether Django's dev server, the Paste server, or Apache I ran some profiling in order to narrow the problem even further. This first link is a profile of the view that displays the form. This view actual doesn't do much, as I said, it pretty much just displays the form. When the form is submitted via a POST request, it is sent to this second view (the second link). This is where the upload takes place, the processing happens, and the stats are finally displayed. http://paste.e-scribe.com/1564/ http://paste.e-scribe.com/1565/ Someone suggested that an already pending patch would fix the problem. Ticket 1484, which has been superseeded by Ticket 2070 (http://code.djangoproject.com/ticket/2070) has to do with streaming uploads. This afternoon I applied the most recent patch in Ticket 2070, and suprisingly, not only did it work, it also didn't have any effect on the upload issue. Still the same 24 seconds. I also discovered some other strange stuff. The 6 MB file which I had been uploading was a DBase file. I uploaded a 7 MB Excel file, and it took 17 seconds. I uploaded a 1 MB Excel file and it took 2 seconds. I tried to upload a 13 MB CSV file and it was at 70+ seconds and still not finished. There doesn't seem to be any common pattern between all this. The filetype really shouldn't make any difference, because as I said earlier, both my Pylons app and Django app were using the same outside library in the same way in order to conver t the file. So I'm a bit stuck here. I'd love to use Django, but I cannot have it running 3x slower than another Python framework. We do a lot of file processing here. Hopefully with all this data someone will be able to come up with some kind of idea as to what the problem might be and what solution can be applied. Thanks, jp --~--~-~--~~~---~--~~ You received this message because you
Re: Serious problems with the way Django handles file uploads
It isn't using FileField, infact it isn't touching the DB or using any kind of manipulator at all. The form consists of a simple box which allows the user to upload a file. The file is then submitted in a POST request to the second view. The second view then calls to an outside library which converts the file to a tab-delimited file, then the view continues on and does statistical work. None of my code has anything to do with the mail or email stuff. It is worth noting that parse_file_upload in django.http uses those email and mail libraries a lot. For what I don't know. But like I said, Im not calling to the DB or doing anything else. Really all Django itself is doing is uploading the file and then displaying a template. James Bennett wrote: > On 9/13/06, jp <[EMAIL PROTECTED]> wrote: > > http://paste.e-scribe.com/1564/ > > http://paste.e-scribe.com/1565/ > > It's hard to infer exactly what's going on without knowing more about > the actual code you're using; for example, that first set of profiler > output is spending over 40% of its time in django.core.mail and > related Python email modules, yet AFAIK there's nothing in FileField > or the automatic manipulator for a model with a FileField which should > get into that code. > > Could you provide some more detail about what your code is doing, > especially anything it's trying to do with respect to sending email? > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Serious problems with the way Django handles file uploads
Turns out when I was trying to apply ticket 2070, I was forgetting to actually enable the upload middleware. I've enabled it now, but I'm getting errors. This patch *should* fix the problem if I can get it working. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Serious problems with the way Django handles file uploads
I found out a solution to the problem! Today I thought about possibly subverting Django's way of parsing file uploads and using something else to do so, while still using Django itself for everything else. After a question in IRC about it, someone mentioned that request.POST and request.FILES are evaluated in a 'lazy' fashion; the form isn't actually parsed until either of those are explicity referenced in your code. With this in mind, I figured I could use the code from Pylons that does form parsing. This part of Pylons is actually done using a portion of Paste, paste.request.parse_formvars. http://pythonpaste.org/module-paste.request.html#parse_formvars Using this, I was able to simply say: 'from paste.request import parse_formvars' And then in the view itself: input = parse_formvars(request.environ) to be more consistent with Django, I believe I couldn't done something like: request.POST = parse_formvars(request.environ) Basically this just bypassed Django's handling of the form and used Paste instead. I'm happy to say that was literally the only change I had to make in my code. Of course I didn't say request.FILES['upload'].filename, but input['upload'].filename did it all for me. Even better news is...this version is actually *faster* than the Pylons version. Only by a second or less, but it is faster. Everything works fine. I'd like to suggest a few things: 1. Ticket 2070 needs to be looked at. Currently it incorporates both an AJAXY upload progress indicator AND a fix on the upload system. These two items should not be bundled; one is drastically more important than the other 2. I honestly can't even say that Ticket 2070 would've fixed my problem, it might. But it my be a good idea to include paste.request.parse_formvars as a 'light' and efficient way of parsing file uploads. It is licensed under an MIT license, there would be no problem including it, but it might be very important if Ticket 2070 isn't a fix to the problem I was having. Hope to hear back from someone, and thanks for those that helped me out along the way. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Serious problems with the way Django handles file uploads
Actually I did apply that patch and it worked. Problem is, even though it kept the dev server form simply stopping when I went to upload large files, it did not speed up the upload process at all. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Test framework in memory database
Mikeal Rogers wrote: > > Excuse me for being very dense here, but I'm missing what's going on > > here. You found a problem with in-memory SQLite and then did or didn't > > solve it? Or you just worked around it? > > Sorry for the confusion. > > I worked around it. It's still an outstanding issue, I'm not that > familiar with the differences between using an in memory database and > using regular sqlite and have hit my limit on being able to track it. I'd bet this is related to some issues I've seen in trying to get the multi-db branch tests passing post r3661. The trouble is (or seems to me to be) that anything that uses the test client causes the request_finished signal to fire, which causes connection.close() to be called, which makes the in-memory database go away, or at least lose all of the tables, etc, that were populated into it during the "request". JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: bump: give Gabor (or somebody else) a unicode branch in svn
James Bennett wrote: > On 10/13/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > > I know it's off-topic, but do you have any thoughts as to which > > branch? > > Based on my sporadic glances, I'd agree with you that row-level perms > and multi-db both look like good candidates to be finalized and > merged. I've been away for a bit (moving, limited access), so multi-db hasn't gotten a trunk merge in a few weeks. And at last update, only the postgres backend was passing all tests. SQLite still has problems with the test client snuffing out the in-memory db, mysql has problems because some of the multi-db-specific tests are looking for postgres quoting style in the generated sql, and I don't have access to any other backends to test with. I may be able to make time this week to merge up to trunk latest, but I can't guarantee that. The point is, though I hope multi-db will be merge worthy sometime soon, as of today I don't think it is. Sorry. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: bump: give Gabor (or somebody else) a unicode branch in svn
Malcolm Tredinnick wrote: > And my apologies to use, JP: I still haven't gotten around to reviewing > all the changes as I promised I would. It's not forgotten, more that > Life has gotten in the way of Fun Projects a lot lately and there aren't > enough hours in the day. No need to apologize. The same applies over here. It's been a very busy 6 weeks or so, some good busy and some awful busy, and my attention has been anywhere but on Fun Projects. So don't worry about it; review it when you get a chance, and if interest remains I'll merge it back up with trunk HEAD and try to find time to fix or at least document the test failures with sqlite and mysql. Thanks, JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
The create/update/delete generic views need a 'message' parameter...
Something that is fairly common in web applications are indicator messages. For example, after you've posted an article, the site should echo back to you 'Article x created'. This is important because it let's the user know what is going on. Unfortunately with Django generic views, particularly the create/update/delete ones, there isn't any way to easily pass a success message to be displayed via a template. That in my opinion needs to be a parameter option, because otherwise it is fairly difficult to check as to whether the create/update/delete method was a success and thus the message needs to be passed into the template. It would also be nice for the auth generic views (login, logout), as an easy way to say 'You are logged in, x', or 'You are logged out', etc. Does anyone else agree with me? It would just take the form of a keyword argument. For example: from django.views.generic.create_update import create_object def create_job(request): return create_object(request, model=Job, post_save_redirect='/', login_required=True, message='Job added') --~--~-~--~~~---~--~~ 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: The create/update/delete generic views need a 'message' parameter...
James, I discussed with you some on IRC earlier my situation, but I'll bring it up here so others can read it. The problem with your suggestion is it will only work for authenticated users. If you have anonymous users, using messages like that simply won't work. The Django docs suggest using the session, but updating the session properly, ie to say request.session['message'] = 'Job created' is pretty much impossible to do accurately because there is no way to know whether the generic view method was a failure or a success. The only other option is to pass your message as a POST param via the redirected URL, but that completely destroys the 'pretty URLs' that most devs aim for. That is why I feel like the only way to properly fix this is to have a 'message' param in the generic views itself which can properly give an indicator message if the method succeeds. On Nov 13, 3:30 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 11/13/06, jp <[EMAIL PROTECTED]> wrote: > > > Something that is fairly common in web applications are indicator > > messages. For example, after you've posted an article, the site should > > echo back to you 'Article x created'. This is important because it > > let's the user know what is going on.You might want to check out the > > 'messages' feature of the auth app[1], > which essentially does the same thing, and has support via a context > processor to ensure it shows up in any view that uses RequestContext > (which includes all of the generic views). The messages you see in the > admin about "object was created successfully" or "object was updated > successfully" are examples -- they're Message objects which are > attached to your user when you take a particular action, and cleared > after being displayed. > > [1]http://www.djangoproject.com/documentation/authentication/#messages > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin --~--~-~--~~~---~--~~ 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: The create/update/delete generic views need a 'message' parameter...
You are correct Collin. :) I noticed that myself but couldn't go back and edit it or anything. James, also I noticed that the messages system even with authenticated users won't work properly with generic views because again, there is no way to know whether the update/creation was a success or not. On Nov 13, 3:51 pm, "Collin Grady" <[EMAIL PROTECTED]> wrote: > Point of clarification, it'd be a GET param, since you can't add POST > in a redirect ;-) > > -- > I do not fear computers. I fear the lack of them. > -- Isaac Asimov --~--~-~--~~~---~--~~ 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: The create/update/delete generic views need a 'message' parameter...
Nymbl, I definitly agree that something like that would be ideal and is important if developers are able to get the full power out of generic views. On Nov 14, 8:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I have an idea. Instead of a 'message' parameter, there could be a > on_success, on_error callable parameter in the function. I don't know > what the parameters to the callback would be, but this is the rough > idea: > > def on_error(request, ?other parameters?): > request.session['message] = "Not saved:" > ... > def on_success(request, ?other parameters?): > request.session['message'] = "Saved" > ... > def create_job(request): > return create_object(request, model=Job, post_save_redirect='/', > login_required=True, on_error=on_error, on_success=on_success) > > I don't know. Just an idea --~--~-~--~~~---~--~~ 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: django.contrib.formtools: High-level abstractions of common form tasks
> > You could probably have a partial validation, per-page, and a complete > > one on the final page, essentially re-validating all the fields. > > HTML-escaping of these hidden fields values would be mandatory in all > > cases anyway. > > Yes, my thoughts exactly. Per-page validation, plus a final validation > after the last step of the wizard. What I've always done in these cases is carry a MAC along with the hidden data and just validate that the hidden data hasn't changed by re-hashing it after each form submit. You don't really need to re-validate the already-validated data, you just need to ensure that it hasn't changed since you validated it. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
multi-db branch: looking for a new maintainer
Hi all, I'm afraid that I am not going to have time in the future to continue maintaining and merging up the multi-db branch. It's diverged so far from trunk that any trunk change that touches management.py or models results in hours of hand-merging and svn detective work... hours that I just don't have to give right now. I'd hate to see the branch die, since I think it will be of use to people, so I'm hoping that someone else will step forward to take over ownership, until such a time as the branch is reviewed and merged or rejected. Of course I'll be more than happy to help the new maintainer get up to speed on the changes and new features in the branch, and will always be available to answer questions about it -- as much as time allows anyway. :) Any takers? JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django is really starting to muddle MVC, and it has me concerned
Today I needed to do something perhaps not entirely uncommon. I wanted to create a form that contained elements from both the User model as well as the UserProfile object I had attached to it. At this point, I had an option. I could either define a completely separate new form that had fields relating to each of the correct fields and manually setup the correct validation, or I could derive a form using newforms.form_for_fields() and select what fields I needed from the model. This was attractive to me as the model already had validation-related data due to specifying options such as choices that the admin app could pick up. So I ended up doing the former. It wasn't very pretty, but it worked. I soon found out, hwoever, that newforms doesn't even bother looking at the choices field for a CharField, and renders them as a regular text field instead of a select box as I expected. At this point I subclassed the form generated from newforms.form_for_field() and manually changed the widgets for the fields that I need to. My final result ended up being this piece of code. http://dpaste.com/8382/ Now to be perfectly honest, this code is very ugly, and it doesn't seem Pythonic at all. A freshly defined newform would be much better. However, doing so would mean duplicating information in both my model and my form. This breaks down DRY. To fix this I could remove all validation/display related information from my model, but then the admin application won't work. If I want the admin application to work I have to intentionally break DRY. This seems to me to be a very bad spot to put Django in. Not only is it confusing to new users (should I derive my forms from models or have my forms separate from models?), but it is also mixing up the model with the view which is also very bad. I just observed this, and I think that there needs to be some serious thought about this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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: Django is really starting to muddle MVC, and it has me concerned
Oh, in addition I was wondering what the 'right' way to do this would be at the current time? On Apr 12, 12:48 pm, "jp" <[EMAIL PROTECTED]> wrote: > Today I needed to do something perhaps not entirely uncommon. I wanted > to create a form that contained elements from both the User model as > well as the UserProfile object I had attached to it. > > At this point, I had an option. I could either define a completely > separate new form that had fields relating to each of the correct > fields and manually setup the correct validation, or I could derive a > form using newforms.form_for_fields() and select what fields I needed > from the model. This was attractive to me as the model already had > validation-related data due to specifying options such as choices that > the admin app could pick up. > > So I ended up doing the former. It wasn't very pretty, but it worked. > I soon found out, hwoever, that newforms doesn't even bother looking > at the choices field for a CharField, and renders them as a regular > text field instead of a select box as I expected. At this point I > subclassed the form generated from newforms.form_for_field() and > manually changed the widgets for the fields that I need to. My final > result ended up being this piece of code. > > http://dpaste.com/8382/ > > Now to be perfectly honest, this code is very ugly, and it doesn't > seem Pythonic at all. A freshly defined newform would be much better. > However, doing so would mean duplicating information in both my model > and my form. This breaks down DRY. To fix this I could remove all > validation/display related information from my model, but then the > admin application won't work. If I want the admin application to work > I have to intentionally break DRY. > > This seems to me to be a very bad spot to put Django in. Not only is > it confusing to new users (should I derive my forms from models or > have my forms separate from models?), but it is also mixing up the > model with the view which is also very bad. > > I just observed this, and I think that there needs to be some serious > thought about this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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: Django is really starting to muddle MVC, and it has me concerned
I feel a bit ashamed. I came across a post about the newforms-admin stuff and one of the prime goals is to move the admin information out of the model. Yay! I guess I will be writing my code with that in mind from here on out. On Apr 12, 12:50 pm, "jp" <[EMAIL PROTECTED]> wrote: > Oh, in addition I was wondering what the 'right' way to do this would > be at the current time? > > On Apr 12, 12:48 pm, "jp" <[EMAIL PROTECTED]> wrote: > > > Today I needed to do something perhaps not entirely uncommon. I wanted > > to create a form that contained elements from both the User model as > > well as the UserProfile object I had attached to it. > > > At this point, I had an option. I could either define a completely > > separate new form that had fields relating to each of the correct > > fields and manually setup the correct validation, or I could derive a > > form using newforms.form_for_fields() and select what fields I needed > > from the model. This was attractive to me as the model already had > > validation-related data due to specifying options such as choices that > > the admin app could pick up. > > > So I ended up doing the former. It wasn't very pretty, but it worked. > > I soon found out, hwoever, that newforms doesn't even bother looking > > at the choices field for a CharField, and renders them as a regular > > text field instead of a select box as I expected. At this point I > > subclassed the form generated from newforms.form_for_field() and > > manually changed the widgets for the fields that I need to. My final > > result ended up being this piece of code. > > >http://dpaste.com/8382/ > > > Now to be perfectly honest, this code is very ugly, and it doesn't > > seem Pythonic at all. A freshly defined newform would be much better. > > However, doing so would mean duplicating information in both my model > > and my form. This breaks down DRY. To fix this I could remove all > > validation/display related information from my model, but then the > > admin application won't work. If I want the admin application to work > > I have to intentionally break DRY. > > > This seems to me to be a very bad spot to put Django in. Not only is > > it confusing to new users (should I derive my forms from models or > > have my forms separate from models?), but it is also mixing up the > > model with the view which is also very bad. > > > I just observed this, and I think that there needs to be some serious > > thought about this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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: Django is really starting to muddle MVC, and it has me concerned
Alright, well now I'm even more confused. The Admin class is being moved out of the model, but the display information will remain on individual fields so that newforms can use it via form_for_model() and form_for_fields()? That doesn't make a whole lot of sense to me. I would think that with the newforms admin stuff it would be an ideal time to completely remove all display-related information from the models. It really just doesn't belong there. On Apr 12, 1:22 pm, "jp" <[EMAIL PROTECTED]> wrote: > I feel a bit ashamed. I came across a post about the newforms-admin > stuff and one of the prime goals is to move the admin information out > of the model. > > Yay! I guess I will be writing my code with that in mind from here on > out. > > On Apr 12, 12:50 pm, "jp" <[EMAIL PROTECTED]> wrote: > > > Oh, in addition I was wondering what the 'right' way to do this would > > be at the current time? > > > On Apr 12, 12:48 pm, "jp" <[EMAIL PROTECTED]> wrote: > > > > Today I needed to do something perhaps not entirely uncommon. I wanted > > > to create a form that contained elements from both the User model as > > > well as the UserProfile object I had attached to it. > > > > At this point, I had an option. I could either define a completely > > > separate new form that had fields relating to each of the correct > > > fields and manually setup the correct validation, or I could derive a > > > form using newforms.form_for_fields() and select what fields I needed > > > from the model. This was attractive to me as the model already had > > > validation-related data due to specifying options such as choices that > > > the admin app could pick up. > > > > So I ended up doing the former. It wasn't very pretty, but it worked. > > > I soon found out, hwoever, that newforms doesn't even bother looking > > > at the choices field for a CharField, and renders them as a regular > > > text field instead of a select box as I expected. At this point I > > > subclassed the form generated from newforms.form_for_field() and > > > manually changed the widgets for the fields that I need to. My final > > > result ended up being this piece of code. > > > >http://dpaste.com/8382/ > > > > Now to be perfectly honest, this code is very ugly, and it doesn't > > > seem Pythonic at all. A freshly defined newform would be much better. > > > However, doing so would mean duplicating information in both my model > > > and my form. This breaks down DRY. To fix this I could remove all > > > validation/display related information from my model, but then the > > > admin application won't work. If I want the admin application to work > > > I have to intentionally break DRY. > > > > This seems to me to be a very bad spot to put Django in. Not only is > > > it confusing to new users (should I derive my forms from models or > > > have my forms separate from models?), but it is also mixing up the > > > model with the view which is also very bad. > > > > I just observed this, and I think that there needs to be some serious > > > thought about this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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: Django is really starting to muddle MVC, and it has me concerned
Numerous arguments applicable to different fields. choices, radio_admin, editable, blank and several others. Some of them have absolutely nothing to do with the model/database itself, they exist purely for form/display-related purposes. On Apr 12, 1:34 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 4/12/07, jp <[EMAIL PROTECTED]> wrote: > > > That doesn't make a whole lot of sense to me. I would think that with > > the newforms admin stuff it would be an ideal time to completely > > remove all display-related information from the models. It really just > > doesn't belong there. > > What "display-related information" are you referring to? > > -- > "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 [EMAIL PROTECTED] 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: Django is really starting to muddle MVC, and it has me concerned
Adrian, correct me if I'm wrong, but the newforms-admin branch currently doesn't have arguments such as choices, editable, and other admin-related arguments removed from model fields, correct? Are they going to be removed? That's what I'm concerned about, not the Admin class itself. I'm concerned about tagging model fields with arguments that aren't directly related to the DB. On Apr 12, 3:23 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 4/12/07, jp <[EMAIL PROTECTED]> wrote: > > > Numerous arguments applicable to different fields. > > > choices, radio_admin, editable, blank and several others. > > > Some of them have absolutely nothing to do with the model/database > > itself, they exist purely for form/display-related purposes. > > Hi jp, > > The options that apply to the admin interface have been factored out > as options to the admin class. Here's more information: > > http://code.djangoproject.com/wiki/NewformsAdminBranch > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] 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: multiple-db-support
I replied to Ben via email, but for the group, again: multi-db needs a new maintainer. I don't have the time to keep up with merging it, let alone to add new features or complete the documentation. I think Ben has some excellent ideas here and would be a great maintainer candidate. JP On Jun 5, 12:27 am, "Ben Ford" <[EMAIL PROTECTED]> wrote: > Hi JP, > I've been using your multiple-db-support for sometime now and i wondered if > you are still actively developing it? I have a couple of suggestions/queries > to do with a few of my specific needs and I would guess those of others... > There are a couple of tickets about this on trac, but I might try and do > some bits independently so I wanted to ask for your feedback... > - I'd really like if I could define a FK relationship that spans > databases, at present that will work but the backwards relationship is > broken and it throws a validation error. > - I'd like this 'spanning foreignkey' to not break the django ORM... so > that Model.objects.filter(fk_class__column='whatever') would still work. > I'm guessing that this would be quite a lot of work... Probably consisting > of: > - A new type (or types) of Field, perhaps OtherDBForeignKey or something > > - A new type of descriptor for each of these new field types > - Some new logic in django.db.models.query to catch the case of a db > spanning relationship and split the queries up > - Finally some way to build the sql so that it looks like SELECT > [columns,] from first_table where pk in (list_of_pk_values); the list will > be generated from a separate query as a result of splitting the queries up > in the last step. > What do you think about the amount of work that would be needed to get all > this working? > As an aside i have a copy of multiple-db-support that I've merged with trunk > as of rev 5371, it might be good to get this checked into django so other > people can work on it, if there's still any interest... > Thanks in advance, > Ben > > -- > Regards, > Ben Ford > [EMAIL PROTECTED] > +628111880346 --~--~-~--~~~---~--~~ 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: Connection pooling
Hmmm... Some question come to my mind now... 1. Does django uses only one connection for the whole process? 2. Does it open and close a connection once for every request? 3. Can django handle many requests at once (multi-threaded or something else)? -- JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
