On 8/23/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> * The template system being "dumbed down" for designers? Going to call
> BS on that too. The real complaint here seems to be that the template
> system doesn't include a programming language, and personally I don't
> think it should. If ther
James Bennett wrote:
> On 8/26/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
>> Yes, a lot of things would be better handled at the database level,
>> e.g., inheritance, views, more advanced validation, but it would break
>> database independence.
>
What would be really useful for django is:
1.
On 8/26/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
> Yes, a lot of things would be better handled at the database level,
> e.g., inheritance, views, more advanced validation, but it would break
> database independence.
Inheritance makes sense in the ORM, because we want to be able to map
inheri
James Bennett wrote:
> 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 leakin
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 m
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.
In your words this looks us
> In my experience such simple behavior is rarely needed. When you
> actually need a pool it means that your app become pretty large so it
> requires not only static pool but also other settings like minimum spare
> connections, maximum spare connections, keep-alive timeouts etc... So
> this becom
Kevin Menard wrote:
> I've experienced the exact opposite. When I can say in a config file
> that I want 10 connections in a pool, that's a lot easier for me than
> setting up an external utility.
In my experience such simple behavior is rarely needed. When you
actually need a pool it means tha
On 8/22/06, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. It's easier to "switch out" pooling utilities this way, or to
> switch between pooling and not pooling as circumstances dictate. When
> your framework tries to do connection pooling for you, it
> automatically gets harder and, depending on
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
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
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
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
> > 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
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
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, 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
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
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
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
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,
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
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
> 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/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
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
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
http://www.cmlenz.net/blog/2006/08/the_python_web_.html
Some points I think are reasonable, for example: django configuration
--
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~
30 matches
Mail list logo
