For those interested in multiple database support, I have started
working on it again, and posted my work-in-progress to ticket #4747.
I started from trunk and added things from the multidb branch little
by little, since so much has changed in that area since then.
There is still a lot more that
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
; > 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 spea
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
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.
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
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
> 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 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
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
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
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
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
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
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 :-) ).
--~--~-~--~~---
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
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
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 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 "
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
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 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
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 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
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
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
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
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
I've been hacking away today at a patch for #1142 (multiple database
connection support), which is the last serious technical hurdle to my
company's use of django -- a very itchy itch for me to scratch.
Mostly things have gone well. My basic design is to add, as a
supplement to the current db.con
I've been hacking away at #1142 (multiple database support) a bit more,
with some help from Jon Dugan. As you can see from the patches
attached to the wiki page:
http://code.djangoproject.com/wiki/MultipleDatabaseSupport, the changes
needed to support multiple dbs are many and far-rea
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 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 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, [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
> 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
> 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
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
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
[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
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
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.
hi, i'm using the multiple DB support branch and i'd like to have one
DB be MySQL and one be sqlite, but i can't, because all of django's
generated SQL conforms to the primary DB type. so in this case all the
queries sent to the sqlite DB have backticks, which causes parsing
errors.
can anyone su
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
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
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 ca
ly have to define our own API in
the non-relational branch.
Bye,
Waldemar Kornewald
On Thu, Dec 3, 2009 at 5:10 PM, Russell Keith-Magee
wrote:
> 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
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
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 o
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 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 contri
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 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
> 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 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'
>
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 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
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
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
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
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 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
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
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
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
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',
>
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
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
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
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
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 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
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: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
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 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 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
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 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'
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 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 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
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
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
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
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 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
86 matches
Mail list logo
