On 8/23/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> The problem is that to make it usefull to the user (read: api-user /
> developer), you have to put the model save in a try / except block so
> that if there is a validation error, it can raise the form.
> Otherwise, the user will have to
On 8/23/06, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. I'm not sure I like the idea of manipulators having a 'process'
> method which does everything; it would feel more natural to just try
> 'manipulator.save()', have that save if all is well, and catch any
> validation errors.
The problem
Finally! I've been waiting :)
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> How To Be Sexy, Rule 1: The word "manipulator" has really got to go.
>
> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
> plan in Trac?
>
I know you want to get rid of the concept of
On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
>
> On 24/08/2006, at 2:00 PM, limodou wrote:
>
> >
> > On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> >>
> >> so Limodou.
> >>
> >> what's the next step.
> >> have you got a prototype of it ? or a idea on how it will work?
> >> I've got
On 24/08/2006, at 2:00 PM, limodou wrote:
>
> On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>>
>> so Limodou.
>>
>> what's the next step.
>> have you got a prototype of it ? or a idea on how it will work?
>> I've got a old linux box you can use to host it until it gets
>> popular.
>
>
On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
> so Limodou.
>
> what's the next step.
> have you got a prototype of it ? or a idea on how it will work?
> I've got a old linux box you can use to host it until it gets popular.
No, I haven't a plan about it, just some ideas. If someone make
so Limodou.
what's the next step.
have you got a prototype of it ? or a idea on how it will work?
I've got a old linux box you can use to host it until it gets popular.
I'm more for just storing the meta-data of the project, and let the
owners of the project host it on their own (or googles
On 8/24/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> limodou wrote:
> > I think if this functionality built on django official site is the
> > better, because every djangor can easy find it. I think the first
> > stage could be the index site supplied by django site, and the exact
> > projects
limodou wrote:
> I think if this functionality built on django official site is the
> better, because every djangor can easy find it. I think the first
> stage could be the index site supplied by django site, and the exact
> projects could be found everywhere. And the second stage could be
>
try ./manage.py install, it executes sqlall
Corey
On Aug 23, 2006, at 2:42 PM, [EMAIL PROTECTED] wrote:
>
> I've got the following:
>
> class Page(models.Model):
> name = models.CharField(maxlength=64, db_index=True,
> unique=True)
> description = models.TextField(blank=True)
>
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
> plan in Trac?
I think Brant's rocking the sexiness; the concept of validation
behaving as a try/except block feels nice to me. And bidding good-bye
to 'if errors',
Resurrecting an old thread...
Let's make this happen!
Joseph (in the e-mail below) has spelled out a pretty decent plan for
the new manipulator scheme. I see that we've got another proposal in
Trac by Brant Harris -- http://code.djangoproject.com/ticket/2586.
Let's get something decided and
I've got the following:
class Page(models.Model):
name = models.CharField(maxlength=64, db_index=True,
unique=True)
description = models.TextField(blank=True)
class Text(models.Model):
page = models.ForeignKey(Page, db_index=True,
edit_inline=models.STACKED)
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
I've added the code.google link on the wiki :)
In general people will host their projects at google, sourceforge and
other sites like these. The basic thing what djangoproject.com should
have is a project catalog where all django based projects can be added,
listed, searched etc.
Second thing -
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
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 local, and the DatabaseWrapper
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
I agree with you what absolutely need to be included to the dajngo web
site is at least a pointer to the code repository. It would also be
nice if djangoproject could host the project documentation. However I
think that it would be great to have a sandbox for each project where
visitor can
On 8/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I have the feeling that this is more or less already existing. It is
> called "google code"
> - http://code.google.com/hosting/search?q=label:django
> It is taking 2 min to create a new projet. the only thing missing there
Hello,
I have the feeling that this is more or less already existing. It is
called "google code"
- http://code.google.com/hosting/search?q=label:django
It is taking 2 min to create a new projet. the only thing missing there
is a "meta" wiki where the owner of each project can publish
Hi,
I would find already really useful something like a database with, for
each project a name, description, type of application (middleware,...
or maybe blog, photo manager,...) and a link to the project page (or
blog entrance). All this should have a search function.
This could replace a lot
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 local, and the DatabaseWrapper classes in the backends are all
>
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
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
27 matches
Mail list logo
