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
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
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
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
> 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
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
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
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
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
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
> > 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
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
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
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
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
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
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
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
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
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
25 matches
Mail list logo