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 thought I shouldn't let that stop me from finally
writing a description of the API I proposed at the PyCon sprint.
Each app would have a databases.py file that contains classes used to
define databases connections (in the same manner as classes are used
to define models). Here's an example:
----
from django.db import connections
class LegacyDatabase(connections.DatabaseConnection):
engine = 'sqlite3'
name = '/foo/bar/legacy_db.sqlite3'
----
(And the other DATABASE_* settings (from settings.py) could certainly
be defined as attributes of a DatabaseConnection class.)
JUST FOR TESTING, I propose we allow a database connection to be
specified in a model with a Meta attribute, like this:
----
from django.db import models
from legacy.databases import LegacyDatabase
class LegacyStuff(models.Model):
...
class Meta:
db_connection = LegacyDatabase
----
Jacob expressed his extreme distaste for this at PyCon--for good
reason. (We don't want to encourage coupling models to databases.)
But just so we can get a working patch and start testing, I propose we
go with this for now.
Adrian suggested we allow the specification of database connections
per-app using the new app() function being proposed for settings.py.
I haven't seen a description of this since PyCon, but I think it would
look something like:
app(name='legacy', db_connection='LegacyDatabase')
(I'm sure I'm leaving several important arguments out of this example.)
Perhaps one could implement sharding by defining multiple
DatabaseConnection classes in a databases.py file (we could support
these files at the project level in addition to the app level) and
putting them in a list. Then one could write a function to return the
appropriate database to use and specify that callable in the argument
to the app function (or perhaps as an argument to the url function in
urls.py).
I haven't given any thought to replication. Perhaps someone who needs
this could think about whether this proposal could somehow make
supporting replication easier (or if it might get in the way), or if
it's simply orthogonal to this.
--
Daryl
On Wed, May 28, 2008 at 12:25 AM, koenb <[EMAIL PROTECTED]> wrote:
>
> 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 use of both of these. Although
>> I've disabled to ability to create tickets perhaps the wiki might be a good
>> place to discuss the API? Anyone can clone from the hg repo, give me a shout
>> if you would like push access and I'll sort it out.
>>
>> Cheers,
>> Ben
>>
>> --
>> Regards,
>> Ben Ford
>> [EMAIL PROTECTED]
>> +447792598685
>
> I have been adding some code to Ben's mercurial repo on [http://hg.woe-
> beti.de], see also [http://trac.woe-beti.de].
>
> What has been realised (more or less):
> - connection and model registration
> - validation that related objects use the same connection
> - database_engine specific SQL generation (needs more checking)
> - some management commands accept connection parameter, others can
> generate output for multiple connections
> - syncdb can sync different connections
> - transaction management over connections
> - some tests (needs a lot more work)
>
> This means point 3 of the discussion at [http://trac.woe-beti.de/wiki/
> Discuss] is somewhat working, but definitely needs a lot more testing.
>
> I do need some help with creating tests for all this though.
> I have not figured out yet how to create tests that check that the
> right SQL is being generated for the backend used. (Nor how to test
> the right database was touched by an action, this is quite obvious
> manually, but I do not know how to automate this.)
>
> I put some ideas on using multiple databases for copying (backup or
> migration) of objects (point 4 of the discussion note) in [http://
> trac.woe-beti.de/wiki/APIModelDuplication].
>
> Please comment, add, shoot etc. Any help will be much appreciated.
>
> Koen
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
