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
I've been doing a little reading on multi-db code an wiki. You've
basically been tackling problem #3 (different data types and engines)
- which I didn't care about at all. That's good, I guess.
The way I handle database connections is just by having a connection
pool of different connection objec
Hi Jan,
It sounds like you've made great progress. We have an informal trac and hg
repo set up at trac and hg dot woe-beti.de respectively. you're more than
welcome to add your documentation there! Let me know if you want an hg repo
tp play with too and I'll sort it out for you.
Cheers,
Ben
2008
Hi guys,
I've been heavily swamped with work for college, so I missed this
thead and the few others on multiple databases. Sorry.
I have implemented a proof-of-concept database scaling solution for
Django. It tackles all kind of scaling issues I have seen in Django.
It's purpose is mainly to fin
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 connecti
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 l
Another couple weeks have slipped by and I continue to be crazy-busy.
(But each week I'm busy for a different reason--so I continue to be
foolishly optimistic that I'll soon get a week with some free time.)
Anyway, I don't have time to read this thread through with the care it
deserves, but I tho
On 22 mei, 18:28, "Ben Ford" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've now re-applied Daryls patch (which was against qsrf) to a clone of
> django trunk in a mercurial repo. It's available
> athttp://hg.woe-beti.deandthere's a trac set up for it
> athttp://trac.woe-beti.de. Feel free to make
Simon Willison wrote:
> How about mysql_masterslave or mysql_replicated (I prefer the second)?
Yes, mysql_replicated seems right. Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
On 23 mayo, 13:00, "Mike Scott" <[EMAIL PROTECTED]> wrote:
>
> Maybe having to state a storage location on a per-row level. (IE this could
> happen by overriding the manager, and simply switching DB at selection time.
> or being able to provide the DB info at selection time.)
Maybe i good thing w
On May 22, 6:53 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > Thankfully Ivan Sagalaev's confusingly named mysql_cluster
>
> BTW does anyone have a suggestion how to rename it? I've picked
> mysql_cluster simply because I didn't know that there exists the thing
> named "
You need to be aware that this is quite complicated if your model has
foreign keys in it: if you use the ORM to do queries, the ORM would
have to be so smart as to when to split up your queries instead of
doing joins.
eg you have model A which foreign keys to a User model. For a row of A
that is i
On Fri, May 23, 2008 at 2: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.
> Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this
> problem neatl
I think there is a third issue.
Usage of several RDBMS in one django application simulatneously
For example we maintain two RDBMS: monetdb and postgresql. The latest
and most accessed data is stored in monetdb for performance. After one
month data is moved to posgresql which holds the full archi
Simon Willison wrote:
> Thankfully Ivan Sagalaev's confusingly named mysql_cluster
BTW does anyone have a suggestion how to rename it? I've picked
mysql_cluster simply because I didn't know that there exists the thing
named "MySQL Cluster" (no kidding :-) ).
--~--~-~--~~---
Hi all,
I've now re-applied Daryls patch (which was against qsrf) to a clone of
django trunk in a mercurial repo. It's available at
http://hg.woe-beti.deand there's a trac set up for it at
http://trac.woe-beti.de. Feel free to make use of both of these. Although
I've disabled to ability to create
I have to admit I'm slightly worried about the multi-database
proposal, because at the moment it doesn't seem to solve either of the
multi-db problems I'm concerned about.
The proposal at the moment deals with having different models live in
different databases - for example, the Forum applicatio
I really like this line of thought: having the persistence layer of a
model fixed is a good idea.
Relations is a big issue here: unless we can support relations across
databases, switching connections is always a big opportunity to shoot
yourself in the foot.
I would propose a function that can co
On May 21, 2:16 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> * There needs to be an official API to get a model (or perhaps a
> manager) which references a different "context" --
> ``Model.objects.db`` should be read-only. So you'd call some API
> method, and get back a sort of proxy obj
Hi Jacob,
I'd be interested in your thoughts on a declarative approach to defining the
other databases...? I'll have my mercurial repo synced up to trunk tomorrow
(my time) and I'll re-apply the patch I got from Daryl to it as a starting
point. Hopefully people will be able to have a look through
Hi guys --
Sorry for coming late to the party, but I'm just now catching up on django-dev.
I'm really glad to see you get the ball rolling on multiple db
support, and once I'm dug out from my backlog I'll be happy to start
reviewing code and helping out if I'm needed.
However, before we get to
> Is there a ticket in django we could use to track progress on this? We could
> use 4747, but if we do decide on a new API that might be a bit confusing...
> We could of course just use the mailing list and trac project, thoughts?
There's also http://code.djangoproject.com/ticket/1142. With the
Hi all,
I'll sort out the hg repo (it now needs to point at trunk - not qsrf) and
trac project if I get time this evening and make it public readable for
everyone who's interested.
Is there a ticket in django we could use to track progress on this? We could
use 4747, but if we do decide on a new
Daryl Spitzer wrote:
> If I don't, I see if I can at least make enough time to write up the API
> I came up with at PyCon.
Please do, that would be great.
--
Nicola Larosa - http://www.teknico.net/
--~--~-~--~~~---~--~~
You received this message because you are s
I've unfortunately been too busy to make time to work on this since
PyCon. The last thing I've done (after writing some code on the
flight home) is to send a patch to Ben Ford. Not long after that Ben
created a Mercurial repository (with my patch) and a Trac project.
You'll want to contact him.
On Tue, May 20, 2008 at 4:56 PM, Nicola Larosa (tekNico)
<[EMAIL PROTECTED]> wrote:
> It would be nice to coordinate each one's efforts, to avoid wasting
> time. Ben, Daryl, any news?
Currently, I have not worked on the project, since the proposal,
because of job and university commitments. I plan
Ah, missed that one.
Anyway, I only did the easy parts (that is, getting data in and out of
existing databases).
Thanks for the pointer, I'll try to keep an eye on that.
Koen
On 20 mei, 16:56, "Nicola Larosa (tekNico)" <[EMAIL PROTECTED]>
wrote:
> koenb wrote:
> > For those interested in multipl
koenb wrote:
> For those interested in multiple database support, I have started
> working on it again, and posted my work-in-progress to ticket #4747.
> ...
> Anyway, if anyone is interested in helping, please let me know!
I am going to need this in a month or so. Actions speak louder than
words
yep, tried that.
On Jun 7, 6:54 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I haven't tried this at all myself, as I just use mysql ...but are you
> saying that specifying a different DATABASE_ENGINE in the
> OTHER_DATABASES entries doesn't work? Was just making sure you had
> tried tha
I haven't tried this at all myself, as I just use mysql ...but are you
saying that specifying a different DATABASE_ENGINE in the
OTHER_DATABASES entries doesn't work? Was just making sure you had
tried that.
On Jun 7, 2:02 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> hi, i'm using the mu
Jacob,
I sent you an email about getting commit access to the branch a couple
of days ago. Did you get it, or should I resend?
Thanks,
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
On Jun 23, 2006, at 9:16 AM, [EMAIL PROTECTED] wrote:
> So, would it be possible to create a branch for work on multiple db
> support? If so, and if you can restrict commits to branches only, then
> it would be great for Jon and myself to have commit access there.
Created at http://code.djangopro
[EMAIL PROTECTED] wrote:
> perhaps we could put it all into backend/creation.py.
That's what i had, early, implemented with the firebird backend patch,
put the sequence and triggers sql in creation.py. And now i was trying
retain the management.py intact in terms of functionality, but your
aproa
Wiki page up:
http://code.djangoproject.com/wiki/MultipleDatabaseSupport
The current (sloppy, totally incomplete) patch is attached, along with
a description of where I see it heading.
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribe
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'll start working in that direction tomorrow, if that seems like a
> good plan. I'm going to be mostly internetless for the next 2 weeks or
> so, so it will be a while before I can actually submit a patch that's
> fully functional. But I c
> As I mentioned in another note to this thread, things are the way they
> are because I didn't want to load all the rarely-used reflection stuff
> into memory each time a model is used. That said, if it helps your
> goal (which would be a great Django addition), let's go ahead and make
> those mo
> And, in any case, they need to know the table name (and quite
> possibly database name and connection proxy) for the related tables. So
> you are going to have do a pass through all the models and build up the
> graph of dependencies and make that available to each model at
> construction time a
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'd argue that the right solution here would be to push the brains
> farther out to the edge. Have management functions call class methods
> on models to execute table creation, initial data loading, etc, rather
> than having them poll the
On Wed, 2006-06-07 at 22:25 +, [EMAIL PROTECTED] wrote:
[...]
> However, I've run into a problem that can't be fixed with little
> patches, in django.core.management. Specifically, all of the many
> get_sql_* functions in there pull together sql from multiple models and
> execute it all with
On 6/7/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'd argue that the right solution here would be to push the brains
> > farther out to the edge. Have management functions call class methods
> > on models to execute table creation, ini
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'd argue that the right solution here would be to push the brains
> farther out to the edge. Have management functions call class methods
> on models to execute table creation, initial data loading, etc, rather
> than having them poll the
81 matches
Mail list logo
