On Sun, Dec 6, 2009 at 12:35 AM, Simon Willison wrote:
> On Dec 5, 4:20 pm, Russell Keith-Magee wrote:
>> Trust me - I don't want to do mindless busy work. However, we need to
>> have some sort of answer for the admin interface - Django's admin is a
>> big selling point for Django for some people
On Sun, Dec 6, 2009 at 1:09 AM, Tobias McNulty wrote:
> On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee
> wrote:
>>
>> I don't grant that proposition at all. The admin interface serves as a
>> working example demonstrating that you don't need to use settings to
>> define the way models are u
On Sun, Dec 6, 2009 at 4:16 AM, subs...@gmail.com wrote:
> Oh, I see from a later message by Alex that Meta.using was removed.
>
> -1!
There's a very good reason why this was removed. It isn't a model
level property. Consider - what if contrib.auth.User had a Meta
using='foo' property? If this we
Oh, I see from a later message by Alex that Meta.using was removed.
-1!
-S
On Dec 5, 3:12 pm, "subs...@gmail.com" wrote:
> Isn't 'database' going to be an option in a model's Meta? In this
> situation, is admin going to attempt to do something different?
>
> -S
>
> On Dec 4, 9:18 am, Nan wrote
Isn't 'database' going to be an option in a model's Meta? In this
situation, is admin going to attempt to do something different?
-S
On Dec 4, 9:18 am, Nan wrote:
> > 1) Ignore the problem. Admin works on the default database, but
> > nowhere else. This is certainly less than ideal, but it would
On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee wrote:
>
> I don't grant that proposition at all. The admin interface serves as a
> working example demonstrating that you don't need to use settings to
> define the way models are used.
>
Okay. Do you grant the proposition that "we will (not
On Dec 5, 4:20 pm, Russell Keith-Magee wrote:
> Trust me - I don't want to do mindless busy work. However, we need to
> have some sort of answer for the admin interface - Django's admin is a
> big selling point for Django for some people, so we can't really
> introduce a huge new feature, and then
On Sat, Dec 5, 2009 at 11:33 PM, Waldemar Kornewald
wrote:
> Hi Russell,
>
> On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee
> wrote:
>> On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald
>> wrote:
>>> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
>>> wrote:
The idea of using a
On Sat, Dec 5, 2009 at 11:15 PM, Tobias McNulty wrote:
> On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee
> wrote:
>> As best as I can make out, you're addressing the problem that I've
>> said we aren't addressing - that of presenting a useful end-user API
>> for tasks like master/slave. If I'
Hi Russell,
On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee
wrote:
> On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald
> wrote:
>> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
>> wrote:
>>> The idea of using a function that returns a single string but does
>>> other processing is
On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee
wrote:
> As best as I can make out, you're addressing the problem that I've
> said we aren't addressing - that of presenting a useful end-user API
> for tasks like master/slave. If I'm mistaken, feel free to correct me
> - preferably with some sa
On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald wrote:
> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
> wrote:
>> The idea of using a function that returns a single string but does
>> other processing is a novel approach, and one that I hadn't
>> considered. However, I'm not sure I'm e
On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
wrote:
> The idea of using a function that returns a single string but does
> other processing is a novel approach, and one that I hadn't
> considered. However, I'm not sure I'm especially fond of the idea of
> requiring imports in a settings fi
On Sat, Dec 5, 2009 at 4:07 PM, Johannes Dollinger
wrote:
>
> Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee:
>> [...]
>>> What if the admin was instead fixed
>>> by providing facilities for the more general case outlined above?
>>>
>>> What would this look like? I'm picturing another setting
Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee:
> [...]
>> What if the admin was instead fixed
>> by providing facilities for the more general case outlined above?
>>
>> What would this look like? I'm picturing another setting (bleh) that
>> maps apps and/or models to specific databases. Nam
On Sat, Dec 5, 2009 at 4:42 AM, Yuri Baburov wrote:
> Hi all,
>
> Database -> Model.Manager -> Queryset.
> Save -> Model -> Database
>
> How about making a default Manager that's now "model.Manager" to be a
> setting to override?
> Like, calling current Manager a DefaultManager, and making "Manage
On Sat, Dec 5, 2009 at 3:34 AM, Tobias McNulty wrote:
> The very first "Requirement"/ideal feature on the wiki page reads:
>
> "Different models/applications living on different databases, for
> example a 'blog' application on db1 and a forum application on db2.
> This should include the ability t
On Fri, Dec 4, 2009 at 5:51 PM, Yuri Baburov wrote:
> #Isn't it django.contrib.auth? I'm not sure if collision with
> 'my.superstuff.auth' might happen or not.
It is, but the app registry mechanism in the
'django.db.models.loading' module only uses the "app label", which is
the part of the app mo
AFAICT adding a setting for the default manager just doesn't work because
then any models with custom managers either (a) would lose their custom
manager, or (b) wouldn't get the manager with using().
Cheers,
Tobias
On Fri, Dec 4, 2009 at 3:42 PM, Yuri Baburov wrote:
> Hi all,
>
> Database -> M
Hi Paul, Tobias,
Well, this is god.
Few more use cases that will appear on big django installations:
Sometimes, with master/slave replication (or legacy read-only
databases), users write to one connection, but read from (few) others.
Sometimes, with master/master replication, or different shar
Hi James,
I just suggested a way it *could* work, not how it should work.
Are you objecting to my whole plan or only on Manager part of it?
On Sat, Dec 5, 2009 at 2:49 AM, James Bennett wrote:
> On Fri, Dec 4, 2009 at 2:42 PM, Yuri Baburov wrote:
>> Like, calling current Manager a DefaultManag
On Fri, Dec 4, 2009 at 2:34 PM, Tobias McNulty wrote:
> What would this look like? I'm picturing another setting (bleh) that
> maps apps and/or models to specific databases. Name choices aside,
> this might look something like:
>
> DATABASE_USING = {
> 'django.contrib.auth': 'default',
>
On Fri, Dec 4, 2009 at 2:42 PM, Yuri Baburov wrote:
> Like, calling current Manager a DefaultManager, and making "Manager =
> load(settings.MODEL_MANAGER) or DefaultManager". Or
> Manager.get_queryset calling customizable method. Any.
If a suggestion like this is going to be implemented, I'd pref
Yes, and the similar function for syncdb can be written too!
On Sat, Dec 5, 2009 at 2:42 AM, Yuri Baburov wrote:
> Hi all,
>
> Database -> Model.Manager -> Queryset.
> Save -> Model -> Database
>
> How about making a default Manager that's now "model.Manager" to be a
> setting to override?
> Like
Hi all,
Database -> Model.Manager -> Queryset.
Save -> Model -> Database
How about making a default Manager that's now "model.Manager" to be a
setting to override?
Like, calling current Manager a DefaultManager, and making "Manager =
load(settings.MODEL_MANAGER) or DefaultManager". Or
Manager.get
On Fri, Dec 4, 2009 at 3:03 PM, Paul McLanahan wrote:
> On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor wrote:
>> We will not be adding a setting to pin an application/model to a
>> specific database. We have already removed the Meta.using option. If
>> you want to pin an application to a specific
On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor wrote:
> We will not be adding a setting to pin an application/model to a
> specific database. We have already removed the Meta.using option. If
> you want to pin an application to a specific database it's fairly
> trivial to add a manager and override
On Fri, Dec 4, 2009 at 2:41 PM, Paul McLanahan wrote:
> What will be the default action of manage.py syncdb (without the
> --database option)? Will it create all tables on all DBs, or just use
> "default"? The former would be useful for the simple replication use
> case, but wasteful for partition
What will be the default action of manage.py syncdb (without the
--database option)? Will it create all tables on all DBs, or just use
"default"? The former would be useful for the simple replication use
case, but wasteful for partitioning, and the latter could get tiresome
unless there is a "--dat
The very first "Requirement"/ideal feature on the wiki page reads:
"Different models/applications living on different databases, for
example a 'blog' application on db1 and a forum application on db2.
This should include the ability to assign a different database to an
existing application without
On Fri, Dec 4, 2009 at 11:40 PM, Tobias McNulty wrote:
> Is there a page where one can find a quick summary of the proposed API?
>
> I have some concerns about implementing partitioning through the admin, but
> I expect there's something I'm missing.
>
> For those who haven't been, following the c
Is there a page where one can find a quick summary of the proposed API?
I have some concerns about implementing partitioning through the admin, but
I expect there's something I'm missing.
For those who haven't been, following the conversation closely it'd be nice
to have a quick way to come up to
On Fri, Dec 4, 2009 at 10:18 PM, Nan wrote:
>
>> 1) Ignore the problem. Admin works on the default database, but
>> nowhere else. This is certainly less than ideal, but it would be
>> sufficient for master/slave setups.
>>
>> 2) Use a separate admin deployment for each database. We add a 'using'
>
> 1) Ignore the problem. Admin works on the default database, but
> nowhere else. This is certainly less than ideal, but it would be
> sufficient for master/slave setups.
>
> 2) Use a separate admin deployment for each database. We add a 'using'
> argument to admin.Site(), and append .using() the
On Fri, Dec 4, 2009 at 6:31 AM, Russell Keith-Magee
wrote:
[snip]
> 1) Do nothing special. This is the currently implement behaviour.
As the default, this seems to be the intended behavior only in rare
cases (overwriting a different object from the original) and will
indeed bite.
There is ano
On Fri, Dec 4, 2009 at 7:31 PM, Russell Keith-Magee
wrote:
> IMHO, it's best to leave entirely in the hands of the end user. By
> that reasoning, The current behaviour (1) is actually the right
> solution, along with some documentation explaining the problem and
> some possible solutions - essenti
On Fri, Dec 4, 2009 at 4:38 PM, Simon Willison wrote:
> On Dec 3, 4:10 pm, Russell Keith-Magee wrote:
>> Alex Gaynor's GSoC project to add multiple database support to Django
>> is on the final straight. The only piece of the puzzle that is left is
>> updating contrib.gis - but this hopefully won
On Dec 4, 8:38 am, Simon Willison wrote:
> We now have two blog posts in each database. But, if I do the
> following:
>
> e1.save(using = 'db2')
>
> It has the effect of replacing e3 with the values from e2, since the
> primary keys collide with each other.
I meant to say - the fix is clearly to
On Dec 3, 4:10 pm, Russell Keith-Magee wrote:
> Alex Gaynor's GSoC project to add multiple database support to Django
> is on the final straight. The only piece of the puzzle that is left is
> updating contrib.gis - but this hopefully won't require any major
> changes outside of the gis tree itsel
On Fri, Dec 4, 2009 at 12:20 AM, Waldemar Kornewald
wrote:
> Hi Russell,
> I just noticed a simple documentation bug. See the comment at the
> bottom of this page:
> http://github.com/alex/django/commit/aabfee1571d378dd3b7550573e900850d13e1b9b
You are correct. Thanks for that - I've made the chan
Hi Russell,
I just noticed a simple documentation bug. See the comment at the
bottom of this page:
http://github.com/alex/django/commit/aabfee1571d378dd3b7550573e900850d13e1b9b
Also, I hope you won't define an API for overriding the query class in
the multi-db branch. We'll most likely have to def
Hi all,
Alex Gaynor's GSoC project to add multiple database support to Django
is on the final straight. The only piece of the puzzle that is left is
updating contrib.gis - but this hopefully won't require any major
changes outside of the gis tree itself.
Therefore, I'd like to call for feedback a
42 matches
Mail list logo
