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
in 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 d
AIL 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
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
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]>
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 elem
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 rel
ore 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 bec
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
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
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 n
essage 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
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 t
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
hat.
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" gro
e
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
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 sub
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 ar
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
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-scr
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 are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
to 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 co
delForm 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
--~--~-~--~~~-
ntries)
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
on 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 subsc
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
k.
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 po
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 nee
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
> 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 m
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
, 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
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 Manipulat
;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 e
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 ki
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
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 loc
g 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
--~--~-~--~~~---~--
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-deve
d 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
eck 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.
Hop
ned 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
--~--~-~--~~~---~--~~
Y
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 develope
ly 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" gr
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
45 matches
Mail list logo
