I suppose I'll chime in here since we actually wrote master/slave
replication code on Curse.
Our approach:
- read_cursor and write_cursor exist. write_cursor is what cursor
would point ot.
- get queries all use the read cursor
- saves all use the write cursor
- we had a list of database
On May 22, 9:59 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> 1. Replication - being able to send all of my writes to one master
> machine but spread all of my reads over several slave machines.
> 2. Sharding - being able to put User entries 1-1000 on DB1, whereas
> User entries 1001-2000
On Mon, Jun 16, 2008 at 5:10 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> /me greps over the cx_Oracle 4.3.3 and 4.4 source trees.
>
> It's me or cx_Oracle doesn't have an autocommit symbol at all?. In
> fact, it hasn't
> a set_isolation_level one either.
It does as of version 4.3.2. I know
> To solve it I proposed[1] another strategy: delegate type conversion
> to the backend. Otherwise, I think we will end with too many backend
> flags.
+1
I maintain the external Firebird backend and I would also prefer this
solution.
Ivan Illarionov
Ian,
On Thu, Jun 12, 2008 at 10:49 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
>> connection.autocommit is an attribute and not a method (didn't find a way to
>> cleanly monkeypatch this).
>
> It's also an attribute in cx_Oracle. I'll have to take a look at it
> some time and figure out why it's
On Mon, Jun 16, 2008 at 3:51 PM, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote:
> a. I am thinking that we should instead keep the ``model`` argument,
> but make it optional. Then, we ensure that one of ``model`` or
> ``form_class`` is given. ``form_class``, if given, would override
> ``model``
On Jun 16, 2008, at 2:51 PM, Gary Wilson Jr. wrote:
>
> I was taking a look at the latest patch [1] for #3639 (many thanks to
> Brian Rosner for the hard work), and trying to decide how backwards
> compatible we want to be. (I should also mention that while there has
> been some work done
I was taking a look at the latest patch [1] for #3639 (many thanks to
Brian Rosner for the hard work), and trying to decide how backwards
compatible we want to be. (I should also mention that while there has
been some work done towards class-based generic views in #6735 [3], I
believe that #3639
The QuerySet method examples [1] mostly use the corresponding Manager
proxy method.
Probably QuerySet.create() exists to use querysets where managers are
expected.
An ugly corner case:
cat.article_set.filter(...).create(title=title)
is equivalent to
Article.objects.create(title=title)
Am 16.06.2008 um 20:56 schrieb James Bennett:
> It'd also hurt the reusability of managers (which is a big advantage I
> and others have taken advantage of), because you wouldn't be able to
> keep methods specific to a single model separate from methods which
> aren't, at least not without
On Mon, Jun 16, 2008 at 2:17 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Mon, Jun 16, 2008 at 12:43 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>> * Leave them as they are, and just tell whoever commits #5361 to
>> reference them in the commit message.
>>
>> * Move all of the to the
True. But surprisingly enough, the `create` method is a QuerySet
instance method. And it doesn't use any of the filtering, so
Article.objects.filter(category=cat).create(title=title,
content=content)
doesn't do what you'd expect. (Though `cat.article_set.create` should
work.) Has that
> So then what is the difference between a Manager and a QuerySet?
>
> Nearly everything would work identically if Manager were simply:
>
> class Manager(QuerySet):
> pass
>
> (except actually keeping the magic that connects it to the model
> class.)
Utility methods in managers wouldn't make
On Mon, Jun 16, 2008 at 1:48 PM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> You could as stick them in a single manager as well (and wouldn't
> have to remember which method is available via which manager).
> My point is that one manager per model would be enough to do anything
> you can do
Am 16.06.2008 um 18:49 schrieb James Bennett:
>
> On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>> If you're just want different querysets you can use something like
>> this: http://dpaste.com/53948/.
>
> Or I can use managers and also add other supporting
On Mon, Jun 16, 2008 at 12:27 PM, Jeff Anderson
<[EMAIL PROTECTED]> wrote:
> When we say *Bugs* or "Boogs", do those include usability bugs? I did a
> query on nfa-someday, thinking that they would be appropriate for the 1.0
> final release milestone. There are several that address aesthetic
On Mon, Jun 16, 2008 at 12:43 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> * Leave them as they are, and just tell whoever commits #5361 to
> reference them in the commit message.
>
> * Move all of the to the beta milestone, since they are indeed being
> addressed, and also reference them in the
On Mon, Jun 16, 2008 at 11:15 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> As requested, I've also added milestones for 1.0 alpha, beta, and
> final (as well as a "post-1.0" catch-all). Triagers, feel free to use
> these milestones thusly:
>
> * Any *feature* tickets related to the maybe
So then what is the difference between a Manager and a QuerySet?
Nearly everything would work identically if Manager were simply:
class Manager(QuerySet):
pass
(except actually keeping the magic that connects it to the model
class.)
It would be exactly identical, except that:
* the
Jacob Kaplan-Moss wrote:
As requested, I've also added milestones for 1.0 alpha, beta, and
final (as well as a "post-1.0" catch-all). Triagers, feel free to use
these milestones thusly:
* Must-have feature bugs go in the "alpha" milestone. These basically
should be all nfa-blocker tickets.
El lun, 16-06-2008 a las 10:00 -0700, [EMAIL PROTECTED] escribió:
> I really like the roadmap, but I'm wondering where the docs-
> refactoring work comes in?
It in "Maybe" features, second from the bottom on
http://code.djangoproject.com/wiki/VersionOneFeatures
--
http://www.marcfargas.com --
I really like the roadmap, but I'm wondering where the docs-
refactoring work comes in?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> If you're just want different querysets you can use something like
> this: http://dpaste.com/53948/.
Or I can use managers and also add other supporting methods (which I
also often do).
--
"Bureaucrat Conrad, you
On Mon, Jun 16, 2008 at 10:22 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Has anyone else noticed that development progress seems to have
> exploded since this thread was created? In the weeks/months after the
> qs-rf merge, several days would go by when there wasn't a single
> change
On Mon, Jun 16, 2008 at 10:40 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
>
> Cool. One question I have regarding dates is: is there a target date for
> merging newforms-admin back to trunk? There's an nfa-sprint set for July
> 10-12th which makes it sound like it's still on a branch at that
Hi Mark,
This sounds really useful, I'd suggest sticking this on
djangosnippets.orgfor others to try!
Ben
2008/6/16 lep_man <[EMAIL PROTECTED]>:
>
> Hi Guys,
>
> I did not know to refer to.
>
> i have developed a middleware that helps to debug django application
> in runtime (at production)
>
Hi all,
I've come across some inconsistent behavior when running django under
different conditions. This is in some existing code that has has some
problems and isn't really well written, so I'm going to ask the question
here first to avoid noise on trac before I raise a ticket.
In this code
Has anyone else noticed that development progress seems to have
exploded since this thread was created? In the weeks/months after the
qs-rf merge, several days would go by when there wasn't a single
change committed, but suddenly there have been like 10 per day in the
last few days.
Hi Guys,
I did not know to refer to.
i have developed a middleware that helps to debug django application
in runtime (at production)
the basic idea is if a specific useragent is accessing the site the
middleware class detects and append debug inforamtion that was added
to the request object
Hi folks --
I've posted the final Django 1.0 roadmap, incorporating all great
feedback I got here:
http://code.djangoproject.com/wiki/VersionOneRoadmap
I've also updated the features page
(http://code.djangoproject.com/wiki/VersionOneFeatures) to reflect the
new list and to have a list of
If you're just want different querysets you can use something like
this: http://dpaste.com/53948/.
Things.live.all() vs Things.objects.live().
Am 16.06.2008 um 16:37 schrieb James Bennett:
>
> On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>> Is there a
On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Is there a rationale for multiple managers per model?
Yes, and I at least use them all the time. For example, I'll often
have one manager that does no special filtering, and another that only
returns things with a
On Jun 16, 2008, at 01:38, Jacob Kaplan-Moss wrote:
> No, actually, they can't - language maintainers have access to their
> language(s) only and should only commit there.
Then maybe you should oversee your system.
http://code.djangoproject.com/changeset/7549
> It's true we need someone to step
Second try. I promise there won't be a third.
Is there a rationale for multiple managers per model? Or is it a
that's-how-it's-always-been thing?
If I missed something obvious, I would have received a "wrong list or
rtfm" reply by now, supposedly.
{{{
class AManager(Manager):
pass
Hi,
I updated the patch with regression tests and documentation. Any
feedback welcome!
Julien
On Jun 16, 9:08 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Jun 16, 2008 at 6:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon,
>
> > I'm a bit unsure where to stick
On Mon, Jun 16, 2008 at 6:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> I'm a bit unsure where to stick the regression test for this. Could
> you give any pointer?
The templates regression tests would be a logical place;
tests/regressiontests/templates. Have a poke around to
On Mon, Jun 16, 2008 at 6:03 PM, Vishal Gupta <[EMAIL PROTECTED]> wrote:
>
> can somebody please help me to run the evolve commands ??
Hi Vishal,
Firstly, Django Evolution is not part of the Django project itself; it
is an external project. Please direct questions regarding
Django-evolution to
Hi Simon,
I'm a bit unsure where to stick the regression test for this. Could
you give any pointer?
Thanks!
Julien
On Jun 16, 8:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Jun 16, 10:00 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > I have just added a patch that allows a
On Jun 16, 10:00 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I have just added a patch that allows a simple_tag to receive the
> context as first argument, like inclusion_tag already does. It is
> backward compatible.
>
> I'd like to get some feedback on the code, so feel free to check it
>
Hi all,
the command
Unknown command: 'evolve'
Type 'manage.py help' for usage.
shows the error :
Unknown command: 'evolve'
Type 'manage.py help' for usage.
i tried moving the django evolution directory out of the projects
directory and set it path to PYTHONPATH and PYTHON_PATH but to no
avail
On Mon, Jun 16, 2008 at 3:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
>> A bug/feature keyword won't
>> give you anywhere as much attention, but it will help us filter out
>> features from the list of work we need to focus
Hi all,
I have just added a patch that allows a simple_tag to receive the
context as first argument, like inclusion_tag already does. It is
backward compatible.
I'd like to get some feedback on the code, so feel free to check it
out [1].
That issue has been raised at several occasions both on
El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
> A bug/feature keyword won't
> give you anywhere as much attention, but it will help us filter out
> features from the list of work we need to focus on.
I took the other way around, I'm adding the keyword "post10" for tickets
On Mon, Jun 16, 2008 at 3:21 PM, Shankar Dhanasekaran
<[EMAIL PROTECTED]> wrote:
>
> Hi all,
> A newbie question!
Hi Shankar,
Two quick comments:
1) Cross posting between mailing lists is quite bad form. Find the
mailing list that is appropriate for your purpose, and post your
question once.
Hi all,
A newbie question! Please can anyone answer or direct me to a good resource
that detials the advantage of Django over other frameworks that are in php? PHP
is all over and seems to be more popular than Python in web development. Though
popularity doesn’t always mean it's the best, it
45 matches
Mail list logo
