Hi,
I'm not sure I have a solution, but are you sure it is the built in
server that is slow? Maybe you have some kind of a browser extension
trying to access the Internet. Maybe you should try it using a
different browser and see if there is any difference.
Also, what address are you using to ac
Brantley Harris wrote:
>
> Here is a sample view using a default CreateManipulator:
> def create_poll(request):
> try:
> m = Poll.CreateManipulator()
> poll = m.process(request)
> return HttpResponseRedirect('/poll/%d/' % poll.id)
> except Form, form:
> retu
Hi!
The current django.contrib.auth doesn't really do what I need it to do,
the per-objects-permission branch does adds some of the things I need,
but still not all.
So as I am new to Django and it was advertised, that one can move their
applications from one project to the other without any fuss
El vie, 11-08-2006 a las 19:00 +, [EMAIL PROTECTED] escribió:
> [...]
> [...] The UI elements in the admin
> would be a great start towards a universally useful UI toolkit for
> django, they just need to be opened up a bit, provide hooks and
> callbacks and abstraction so that they can be reus
I am developing a web with django, and in my model I need to superclass
all model classes with a superclass that add some methods.
The problem is django-admin.py create a dummy table not needed for this
superclass. I know that multiple-inheritance can be useful here, but I
can consider som
Hi Mart,
I'm the per-obect-perm developher.
Depends on what magic you are looking for it to do. The
row_level_permissions option in the meta class does two things that can
be rewritten in a way that doesn't need to involve the db.options (meta
class).
The first thing the option does is create a
Hi Chris,
I was just wondering why wasn't there any helper methods to achieve
exactly the same result as you can by editing the Django source (in
your case the django.db), but without editing anything out of your
application's directory.
That way even the code repository wouldn't have invent some
On 8/22/06, Manuel Saelices <[EMAIL PROTECTED]> wrote:
> I patched django for permit abstract classes in a model. My syntax maybe
> doesn't like to someone...
The new and improved model inheritance that Malcolm is working on will
also provide a facility for abstract "base" classes, so I'm thinkin
I'd like an integer field larger than postgresql's integer (2^31).
Any interest in a patch for BigIntegerField?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
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 simplif
On 8/22/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> I'd like an integer field larger than postgresql's integer (2^31).
>
> Any interest in a patch for BigIntegerField?
Matt Croydon submitted a patch a while ago:
http://code.djangoproject.com/ticket/399
It might need a bump.
Felix
--~--~---
On 8/22/06, JP <[EMAIL PROTECTED]> wrote:
> 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 coul
On 8/21/06, limodou <[EMAIL PROTECTED]> wrote:
> Some points I think are reasonable, for example: django configuration
Text really sucks as a medium for certain kinds of things, so keep in
mind that the fact that it's in email will probably result in this
response sounding much harsher than it wa
> 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 Se
On 8/22/06, James Bennett <[EMAIL PROTECTED]> wrote:
> I, for one, would appreciate some more specific criticism. For
> example, just saying that the Django ORM is "a far cry from what
> SQLAlchemy provides" is basically worthless as far as constructive
> criticism; what we need is examples of "he
On 8/22/06, Mart <[EMAIL PROTECTED]> wrote:
>
> Hi Chris,
>
> I was just wondering why wasn't there any helper methods to achieve
> exactly the same result as you can by editing the Django source (in
> your case the django.db), but without editing anything out of your
> application's directory.
>
Am 22.08.2006 um 18:22 schrieb James Bennett:
> Some things that occur to me on other points:
>
> * Admin, auth and comments using Django's own ORM, template system,
> etc.: well... what are we supposed to use? They're Django
> applications, and they leverage as much or as little of Django as they
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
Am 22.08.2006 um 18:22 schrieb James Bennett:
> Some things that occur to me on other points:
>
> * Admin, auth and comments using Django's own ORM, template system,
> etc.: well... what are we supposed to use? They're Django
> applications, and they leverage as much or as little of Django as they
Am 22.08.2006 um 21:49 schrieb Christopher Lenz:
> Am 22.08.2006 um 18:22 schrieb James Bennett:
>> Some things that occur to me on other points:
>>
>> * Admin, auth and comments using Django's own ORM, template system,
>> etc.: well... what are we supposed to use? They're Django
>> applications,
It seems I've been designated the "Django spam maven"; what this means
for you, if you've been getting caught in the Django Trac's spam
filters, is that you need to write me and let me know your IP address
(or the typical range of IP addresses you use) so I can whitelist you.
Once I do this, you
On 8/22/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> You're taking the original statement out of context. The context was
> the often-heard argument that Django lets you replace any subsystem
> if you prefer using a different library. What's less often-heard is
> that if you do so, you are gi
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
why is it then when a framework doesn't meet a persons ideas of the
utopian framework,
it is pronounced as due to 'marketing'?
i just wish that people remembered that a framework is by nature a
set of choices.
do we make it easy to configure at the risk of making it not simple
to learn/sta
On 8/22/06, JP <[EMAIL PROTECTED]> wrote:
> 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
JP wrote:
> 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
On 8/22/06, James Bennett <[EMAIL PROTECTED]> wrote:
> > * More flexible mapping including:
> > - Mapping multiple objects to a table
> > - Mapping multiple tables to an object
> > - Mapping the results of an arbitrary query
> > - Selectively overriding join conditions (including both to and f
> > 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
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 ow
Hi Ahmad,
You completely misunderstand me. I know that per row permissions is
under heavy development and it's in it's own branch. I just expected
that the django.contrib.* applications would have code only under
django.contrib., not under django.db, and god knows where
else.
Mart
--~--~--
On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote:
> http://www.sqlalchemy.org/docs/adv_datamapping.myt
Some of these examples deal with rather exotic use cases that, I
think, are close to the edge of what ORM can reasonably do before the
abstraction starts leaking.
The "map multiple tables to
On 8/22/06, JP <[EMAIL PROTECTED]> wrote:
> 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:
No, the difference isn't in definition; there are pooling utilities
which do "multiple connections to multiple datab
James Bennett wrote:
> The new and improved model inheritance that Malcolm is working on will
> also provide a facility for abstract "base" classes, so I'm thinking
> this would probably be redundant; there's also been discussion on this
> list of how the syntax should work, and IIRC the consensus
On 8/22/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Is this still waiting on django.db.models refactoring? The wiki page
> hasn't been updated in a while.
The wiki page probably isn't the most reliable guide; I haven't looked
at it, but I'd guess that it's been superseded by discussions on this
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.
James Bennett wrote:
> On 8/17/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > IMO, the dependency checking is the easy part. In the README or
> > something, I say MyCoolApp requires the admin app. It's the
> > configuration settings of the admin app that's hairy.
>
> That's what application docu
limodou wrote:
> There are some threads talking about the apps repository already, but
> till now, no repository be found. So I want to suggest again: we
> should build an official project web site to host django apps or
> projects. So we can easy share our source code and exchange our ideas.
> An
On 8/23/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> limodou wrote:
> > There are some threads talking about the apps repository already, but
> > till now, no repository be found. So I want to suggest again: we
> > should build an official project web site to host django apps or
> > projects. So
I created a ticket:
http://code.djangoproject.com/ticket/2594
I also attached a patch that I have done a little testing with and
seems to work ok. I first attacked this at the Node level, but
realized that might not be the best way because the Nodes get rendered
recursively. In order to clean u
James Bennett wrote:
>
> 2. Admittedly I don't have a whole lot of experience in the area, but
> creating and managing a pool of connections to be passed from thread
> to thread just feels like much more hassle and overhead than we really
> need, especially since there are external pooling utilit
40 matches
Mail list logo
