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
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.
>
>
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 newforms-ad
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]
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
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
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
>
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
, "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
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
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
ope 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
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 populat
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
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
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
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 email to django-developers@googlegroups.com
To unsubscribe from this group,
at
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 rece
emy 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
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
"D
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
o 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 t
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
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
> 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
proper
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
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 o
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,
e 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 y
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
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
enario 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@
lume 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
--~--~-~--~~---
t 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
--~--
figure() 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 re
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
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" grou
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
39 matches
Mail list logo
