>
> However, when generic foreign relations are created in a multi-db system
> using Django migrations, separate content-type tables are created for each
> db.
Does this not depend on the db_for_migrate and db_for_write methods of any
relevant database router?
I think only one da
However, when generic foreign relations are created in a multi-db system
using Django migrations, separate content-type tables are created for each
db.
I was wondering if this was the desired behavior, and if that’s the case,
if this ticket is still relevant?
Thank you,
Yasunari Kato
--
Yo
There's merit in both the responses.
Since it's trivial to write your own transaction middleware, I would say
the most important thing is to document that the middleware only affects
your 'default' database. Then it's up to the developer to decide if they
need anything further.
On Sun, Nov 13, 2
Before voting for more magic to the transaction middleware, I'd vote
to remove it altogether. Explicit is surely better than implicit in
this case. The admin already uses commit_on_success, etc.
On Oct 18, 1:22 pm, David Winterbottom
wrote:
> The current implementation of django.middleware.Transa
I'm not sure this is so cut and dry. For two reasons:
1) If a project has a lot of databases configured, created and ending a
transaction in all of them for every request/response cycle could get
expensive, and following that:
2) This is enough of a change in behavior that it shouldn't just be
The current implementation of django.middleware.TransactionMiddleware does
not create a transaction for each database, only the default one
defined by DEFAULT_DB_ALIAS
- https://code.djangoproject.com/browser/django/trunk/django/db/utils.py.
Shouldn't the middleware manage a transaction for each d
http://code.djangoproject.com/ticket/15610
I just stumbled upon this unusual and problematic behavior, and
thought that it might be worth a discussion. Details are in the
ticket.
Regards,
Ed Gutierrez
--
You received this message because you are subscribed to the Google Groups
"Django develop
On Wed, Nov 10, 2010 at 10:06 PM, Ian Kelly wrote:
>
> Yes, here are the settings I'm using:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.oracle',
> 'NAME': 'xe',
> 'USER': 'ikelly',
> 'PASSWORD': 'ikelly',
> 'OPTIONS': {'threaded': T
On Mon, Nov 8, 2010 at 10:02 PM, Ramiro Morales wrote:
> Has anybody had success with this setup i.e. one where the 'default and
> 'other'
> alias pointing to such an Oracle product/install?. Is it possible at all?
>
> If so, could you please share the relevant Django settings file (not
> really,
Andrew,
On Tue, Nov 9, 2010 at 2:15 AM, Andrew Kurinnyi wrote:
> Hi Ramiro
>
> I've been working with Oracle during the sprints after last DjangoCon,
> and had the same problem. I've been told by several people that
> the second db can't be oracle and should be something else, like sqlite.
Thank
Hi Ramiro
I've been working with Oracle during the sprints after last DjangoCon,
and had the same problem. I've been told by several people that
the second db can't be oracle and should be something else, like sqlite.
Here is my db settings.
DATABASES = {
'default': {
'ENGINE': 'djan
Hi all,
I'm setting up a Oracle XE instance on Linux to be able to test Django ORM
changes. This has so far resulted in a couple of small fixes and
a [1]wiki page documenting the process and hopefully any feeback
I get to this email.
Being a total newbie regarding Oracle is th reason I post this
On Jan 23, 7:05 am, Russell Keith-Magee
wrote:
> A full explanation, including an example is in the documentation
> portion of the patch, attached to ticket #12542.
>
> Comments?
This fixed our only (known) blocking problem towards 1.2, thanks so
much.
Brett
--
You received this message becaus
Hi all,
This is a call for comments on what I hope will be the last two
modifications to multi-db support for 1.2.
Barring negative feedback, I aim to commit this at the start of next
week, just in time for the beta-1 feature freeze.
Change 1: Identifying which models are on which database
On Thu, Jan 21, 2010 at 9:54 PM, Ivan Sagalaev
wrote:
> Russell Keith-Magee wrote:
>>
>> class MasterSlaveRouter(object):
>> def db_for_read(self, model, db=None):
>> # Point all read operations to a random slave
>> return random.choice(['slave1','slave2'])
>>
>> def db_for_wri
On Fri, Jan 22, 2010 at 2:03 AM, Yuri Baburov wrote:
> Hi Russell,
>
> On Thu, Jan 21, 2010 at 7:10 PM, Russell Keith-Magee
> wrote:
>> Secondly, while I can see how this information could be useful, it
>> doesn't change the fact that the information is just as easy to manage
>> manually. Syncdb
Hi Russell,
On Thu, Jan 21, 2010 at 7:10 PM, Russell Keith-Magee
wrote:
> On Thu, Jan 21, 2010 at 8:21 PM, Yuri Baburov wrote:
>> Hi Russell,
>>
>> Thanks, I'm rather happy too.
>> It's exactly what we wanted!
>>
>> DB Routing API is even better than some fixed db routing format.
>> I just thoug
On Wed, Jan 20, 2010 at 11:06 AM, Russell Keith-Magee
wrote:
> I've just uploaded a new patch improving the multi-db interface. This
> patch introduces a way to easily configure the database selection
> process, and enables you to assign a database selection mechanism to
> mode
Russell Keith-Magee wrote:
class MasterSlaveRouter(object):
def db_for_read(self, model, db=None):
# Point all read operations to a random slave
return random.choice(['slave1','slave2'])
def db_for_write(self, model, db=None):
# Point all write operations to the m
On Thu, Jan 21, 2010 at 8:21 PM, Yuri Baburov wrote:
> Hi Russell,
>
> Thanks, I'm rather happy too.
> It's exactly what we wanted!
>
> DB Routing API is even better than some fixed db routing format.
> I just thought about any model with GFK, like TagField from django-tagging --
> with multidb, t
Hi Russell,
Thanks, I'm rather happy too.
It's exactly what we wanted!
DB Routing API is even better than some fixed db routing format.
I just thought about any model with GFK, like TagField from django-tagging --
with multidb, to be effectively reusable, it has to know in what DB
to save and loa
On Thu, Jan 21, 2010 at 3:59 AM, Jacob Kaplan-Moss wrote:
> On Wed, Jan 20, 2010 at 10:06 AM, Russell Keith-Magee
> wrote:
>> Ok - so that's the patch. Any comments, queries, or criticisms are welcome.
>
> I'm happy -- +1.
>
> One thing, to point out, though, is that this continues the slow
> pro
On Wed, Jan 20, 2010 at 10:06 AM, Russell Keith-Magee
wrote:
> Ok - so that's the patch. Any comments, queries, or criticisms are welcome.
I'm happy -- +1.
One thing, to point out, though, is that this continues the slow
process of making `Model._meta` a de facto public API -- without being
able
Hi all,
I've just uploaded a new patch improving the multi-db interface. This
patch introduces a way to easily configure the database selection
process, and enables you to assign a database selection mechanism to
models not under your control (e.g., changing database usage for the
contrib
40 that implements something
> similar to what you proposed, along with a few other fixes. I'd be
> interested in hearing any feedback you may have.
Oh - and one more thing - I haven't forgotten about the TEST_NAME
issue - I just wanted to get the foreign key and read-slave stuf
On Sat, Dec 19, 2009 at 10:48 PM, Russell Keith-Magee
wrote:
> On Sat, Dec 19, 2009 at 1:41 AM, Brett Hoerner wrote:
>>
>> I would think read-slaves would be a pretty common application of
>> multidb, but I can only speak to our use case. I know it's a bit late
>> in the game, but we'll have to
allocation.
>
> Russel, can you share your ideas on the matter? I'm about to port (soon-ish)
> my replication backend to new multi-db reality and if you already had some
> thoughts I'd very appreciate to hear it.
Nothing is finalized yet, but here's what I'm work
(soon-ish) my replication backend to new multi-db reality and if you
already had some thoughts I'd very appreciate to hear it.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@go
On Jan 7, 7:33 pm, Russell Keith-Magee wrote:
> then my understanding of your proposal is that the only change is that
> read-slave won't get created under the test setup. But doesn't that
> mean that::
>
> MyModel.objects.using('read-slave').filter(...)
>
> will fall over?
No, not in my ment
On Fri, Jan 8, 2010 at 3:17 AM, Brett Hoerner wrote:
> On Jan 5, 8:09 pm, Russell Keith-Magee wrote:
>> If you're actually doing master/slave in the wild, your guidance may
>> actually be more enlightening than my theoretical navel gazing. In
>> particular - how have you got master/slave configur
On Jan 5, 8:09 pm, Russell Keith-Magee wrote:
> If you're actually doing master/slave in the wild, your guidance may
> actually be more enlightening than my theoretical navel gazing. In
> particular - how have you got master/slave configured? How do you find
> and select slave databases? How does
On Wed, Jan 6, 2010 at 12:42 AM, Brett Hoerner wrote:
> On Dec 22 2009, 4:27 pm, Russell Keith-Magee
> wrote:
>> I'll need to cogitate on this over my Christmas pudding :-)
>
> Did you come to any conclusions, or need any more feedback on the read-
> slave testing issue?
I haven't reached any co
On Dec 22 2009, 4:27 pm, Russell Keith-Magee
wrote:
> I'll need to cogitate on this over my Christmas pudding :-)
Did you come to any conclusions, or need any more feedback on the read-
slave testing issue?
I in no way mean to rush, I just wanted to make sure I didn't (and
don't) miss anything a
Yes, multiple database support was merged into trunk on December 22:
http://www.djangoproject.com/multidb-changeset/
Alex
On Mon, Jan 4, 2010 at 9:40 AM, Joe wrote:
> Has this code been merged to a 1.2 alpha build somewhere or is the
> multi-db branch still the current release? Only
Has this code been merged to a 1.2 alpha build somewhere or is the
multi-db branch still the current release? Only asking because the
first message in the thread indicated a schedule which meant the code
would be merged in before EOY and I just want to make sure I'm on the
right codebase m
> Thanks for the report. I'll try and take a look at this today and work
> out what is going on. In the meantime - if you could open this as a
> ticket, I'd be much obliged.
Russ
I created a ticket for you http://code.djangoproject.com/ticket/12453.
Thanks for looking into this.
- Sean
--
You
On Sun, Dec 27, 2009 at 12:22 PM, Sean Brant wrote:
> I just upgraded to the latest trunk today and the admin now throws an
> exception http://dpaste.com/138130/ when I try and save to a
> ImageField. I messed with it a bit to make sure that it was not
> something else in my code that could be cau
I just upgraded to the latest trunk today and the admin now throws an
exception http://dpaste.com/138130/ when I try and save to a
ImageField. I messed with it a bit to make sure that it was not
something else in my code that could be causing the error. It looks
like the error only occurs when I ha
On Wed, Dec 23, 2009 at 1:32 PM, Michael Manfre wrote:
> With multiple database defined, what is the expected behavior for
> syncdb and the other db related commands?
The management commands all work the same way under multidb - they
only ever work on a single database at a time. If you don't spe
With multiple database defined, what is the expected behavior for
syncdb and the other db related commands? The documentation shows that
it is relatively easy to associate an admin form with a given
database, but is there a way of associated a model or app to a given
database?
Regards,
Michael Man
On Tue, Dec 22, 2009 at 4:55 PM, Brett Hoerner wrote:
> On Dec 22, 4:27 pm, Russell Keith-Magee
> wrote:
> > * Allow TEST_NAME=None to mean "don't try and instantiate this
> > database in test mode"
>
> That sounds good, too.
>
If I was using the slav
On Dec 22, 4:27 pm, Russell Keith-Magee
wrote:
> * Allow TEST_NAME=None to mean "don't try and instantiate this
> database in test mode"
That sounds good, too.
> * Allow a top level TEST_DATABASES setting; TEST_DATABASES would
> override DATABASES; if TEST_DATABASES isn't defined, then TEST_N
On Wed, Dec 23, 2009 at 7:06 AM, Brett Hoerner wrote:
> On Dec 19, 6:48 am, Russell Keith-Magee
> wrote:
>> You're right - read slaves are an intended common use case
>
> I know the branch landed but I'd like to mention another issue
> regarding read-slaves, hope that's OK. :)
>
> Running tests a
On Dec 19, 6:48 am, Russell Keith-Magee
wrote:
> You're right - read slaves are an intended common use case
I know the branch landed but I'd like to mention another issue
regarding read-slaves, hope that's OK. :)
Running tests against code that uses master and read-slaves (but
actually point at
On Sat, Dec 19, 2009 at 1:41 AM, Brett Hoerner wrote:
> I'm not sure if 1.2 intended to fully support read-slaves, but I'll
> post this quick anyway as we've just run into it while trying to
> upgrade at DISQUS.
>
> You might think that having support for multiple databases implies
> that using a
On Sat, Dec 19, 2009 at 3:46 AM, Jani Tiainen wrote:
> Haven't run any tests, but as a small request - I would be very happy that
> you guys take a look ticket #11017 it's quite performance killer to some
> selects on char fields (specially startswith) on Oracle.
This has nothing to do with multi
On Fri, Dec 18, 2009 at 9:43 AM, Russell Keith-Magee wrote:
> Hi all,
>
> This is a second and final call for feedback on the multidb branch.
>
> Barring any objections or the discovery of major problems, my
> intention is to commit this early next week, hitting the alpha 1
> feature deadline by
On Dec 18, 9:50 am, Alex Gaynor wrote:
> I'm wondering if perhaps the most prudent thing to do would be to
> simply remove this check. The end result will be you'll get an
> integrity error on Postgres/Oracle when you try to save (and SQLite
> and MySQL will just let you do whatever).
That would
,
>>
>> This is a second and final call for feedback on the multidb branch.
>>
>> Barring any objections or the discovery of major problems, my
>> intention is to commit this early next week, hitting the alpha 1
>> feature deadline by the skin of our collective te
skin of our collective teeth :-)
>
> There has been one big change since the last call for feedback -
> thanks to Justin Bronn, GIS is now fully multi-db compliant.
>
> There have also been a couple of small changes - mostly integrating
> the contrib applications with multidb featu
the last call for feedback -
thanks to Justin Bronn, GIS is now fully multi-db compliant.
There have also been a couple of small changes - mostly integrating
the contrib applications with multidb features. For example, the
contenttypes app now maintains a cache of content type objects that is
On Tue, Sep 29, 2009 at 11:48 AM, Rob Madole wrote:
>
> Hmm. I just spent some time looking at #11828, and I don't think the
> "syncing one db at a time" will work. The first problem this causes
> is with anything that subscribes to the post sync signal. Content
> type does this, so it can cre
Hmm. I just spent some time looking at #11828, and I don't think the
"syncing one db at a time" will work. The first problem this causes
is with anything that subscribes to the post sync signal. Content
type does this, so it can create permissions. If we sync one db at a
time, I don't see how
On Mon, Sep 14, 2009 at 1:54 PM, Joseph Kocherhans
wrote:
>
>
> On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor wrote:
>>
>> FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon
>> sprints and our conclusion was to have syncdb only sync a single table
>> at a time, and to take a --
On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor wrote:
>
> FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon
> sprints and our conclusion was to have syncdb only sync a single table
> at a time, and to take a --exclude flag (or was it --include?) to
> specify what models should b
On Mon, Sep 14, 2009 at 12:49 PM, JL wrote:
>
> Russell Said:
>
> "I'm yet to be convinced that `Meta: using` is actually a good thing.
> IMHO, it's the very model of a setting that makes it impossible to
> re-use your application. The setting will probably survive into the
> final version, but I
Russell Said:
"I'm yet to be convinced that `Meta: using` is actually a good thing.
IMHO, it's the very model of a setting that makes it impossible to
re-use your application. The setting will probably survive into the
final version, but I suspect we need a much better mechanism than
`Meta: using
On Fri, Sep 4, 2009 at 8:56 AM, Craig Kimerer wrote:
>
>
> On Thu, Sep 3, 2009 at 5:00 PM, Russell Keith-Magee
> wrote:
>>
>> On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer
>> wrote:
>> > I've spent a little time using this branch and looking at the
>> > possibility of
>> > using it with my projec
> > is not created first, then the tests fail with an exception that the
> > django_content_type table does not exist. For now I have just hacked it
> so
> > the default table is created before any of the others. Perhaps there is
> a
> > better way to fix this proble
On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer wrote:
> I've spent a little time using this branch and looking at the possibility of
> using it with my project. Below is a short list of problems and ponies that
> I have encountered (or want).
>
> 1. It'd be awesome if we could mark certain databas
Aug 19, 2009 at 5:54 PM, JL wrote:
> >
> > > Hi Alex,
> >
> > > Thanks so much for the effort you've put into this. We've begun using
> > > your code relatively extensively at my work. For what it's worth,
> > > we're an enterpris
t into this. We've begun using
> > your code relatively extensively at my work. For what it's worth,
> > we're an enterprise Java shop that offers a software as a service
> > product to over 400 customers that are some of the biggest retailers
> > and manufactu
;ve begun using
> your code relatively extensively at my work. For what it's worth,
> we're an enterprise Java shop that offers a software as a service
> product to over 400 customers that are some of the biggest retailers
> and manufacturers in the world. Because of multi-d
iggest retailers
and manufacturers in the world. Because of multi-db we're now able to
use Django in a useful way to do prototyping, proof of concept work
and internal tools. Hopefully in the future, we can move more toward
Django as well.
Last week over email, you asked me to share my impressions of w
Hey all,
It seems GSOC has finally come to a close and so I'm giving my final
status update as a part of GSOC (but I'm not going anywhere!). When
we last left off I had just gotten Oracle support working, however
after reviewing with Russ we agreed that the solution was a good bit
too hacky, and
On Wed, Aug 5, 2009 at 2:54 AM, Roman Vorushin wrote:
>
> Alex,
>
>>If anyone has access to an Oracle DB (or any other backend with a
>>custom query object and doesn't mind doing the small bit of porting)
>>and wouldn't mind testing it out in an env with both Oracle and
>>another DB that would be
Alex,
>If anyone has access to an Oracle DB (or any other backend with a
>custom query object and doesn't mind doing the small bit of porting)
>and wouldn't mind testing it out in an env with both Oracle and
>another DB that would be most appreciated
I have access to Oracle database (one of my D
Hey all,
This week I implemented the metaclass based solution for backwards
compatibility in the Field API that Jacob suggested last week. Then I
implemented by first stab at a solution to the Oracle/backend with
custom query object problem. However, I don't have access to any of
the the DBs I'
Thanks for you input Justin.
I just went on and tried using Django ORM natively on the application
it self (to stay under django) and Elixir on all master database
interactions.
After a little effort, the results were great and I did achieve the
behaviour I expected. I'm positively surprised with
On Tue, 28 Jul 2009, Ricardo Santos wrote:
> What is the current status of the multi version support? I mean will
> it be merged with trunk any time soon?
... snip ...
I think this is slated for the 1.2 timecycle. The GSoC istelf ends
sometime in late August, so that's likely the earliest tim
Hi Alex
What is the current status of the multi version support? I mean will
it be merged with trunk any time soon?
I ask you this because I am at a early stage of designing the
architecture of a new project, and this will have to support several
clients (separate databases) but connected by a m
Hey all,
I didn't get a ton of code written this week, however I have a very
clearly laid out plan for how to handle custom Query classes now.
It's my goal to get the code written and done this weekend while I'm
at PyOhio (if you're in the Columbus area please come on out, it
promises to be a gre
Hey all,
This week I made the final major API changes, updating the
get_db_prep_* methods to recieve connection, and work in a backwards
compatible method. I also fixed the bug with using
__in=queryset.using('other_db'), right now it raises an exception, but
in the future I'll update it to just
Hey all,
This week was fairly productive. I got a lot of good docs done this week,
as well as implementing the using option in the inner Meta class. For this
next week I'm writing up a detailed account of the last API changes that
multi-db will need. Specifically with resepect to get_db_
need to be given an extra parameter
to be multi-db compatible, but that would break any existing custom fields.
It may just be that I need to write a little bit of introspection code, but
we'll have to see.
That's all for this week. As always if there are any questions,
suggestions, flam
Hey all,
This past week I mostly finished off the m2m-refactoring work this week as
well as fixing a few bugs Russ spotted in the multi-db code. For this next
week I think I'm going to be working almost exclusively on docs, as Russ's
wife just had a baby so I think spamming him with s
Hey all,
Sorry about the delayed update, wanted to touch base with my mentor on a few
small issues before firing this off. I spent last week augmenting
ManyToManyFields to use a full Model internally, so we can remove some hard
coded SQL. I've been doing this on a separate branch since it's a fa
Hey all,
This has been a productive week for multiple database support in Django.
Firstly I got all my original work into Django's SVN repository, in
more-or-less atomic commits (they weren't perfect, but unfortunately most of
the early work was anything but linear). Secondly all tests are now pa
Hey All,
Sorry about the delayed updated, I got busy on Friday and then I had the
dash through the weekend. During the last week I implemented multiple
database support for transactions (which was necessary to solve the postgres
DDL problems I mentioned last week). I got this ton and have gradua
If you recall the conversation between Alex and Simon, it will support
this.
-justin
On May 29, 2009, at 9:29 AM, Marco Louro wrote:
>
> Hey Alex,
>
> Not sure if this is the right place, but I guess you're the right
> person to ask..
>
> Will Multi-BD be flexible enough that it will allow
Hey Alex,
Not sure if this is the right place, but I guess you're the right
person to ask..
Will Multi-BD be flexible enough that it will allow to choose a DB at
runtime, depending on something like the user or the domain and not
tied to models at all? From what I've read that's not possible rig
On Sat, May 23, 2009 at 12:06 PM, Alex Gaynor wrote:
> And I didn't actually finish writing before sending grand...
>
> So the issue is one of the remaining 1.1 tickets,
> http://code.djangoproject.com/ticket/9964 , has patches that rewrite
> basically all of the transaction handling code. Can a
And I didn't actually finish writing before sending grand...
So the issue is one of the remaining 1.1 tickets,
http://code.djangoproject.com/ticket/9964 , has patches that rewrite
basically all of the transaction handling code. Can anyone comment on
whether those patches are likely to be represen
Hey all,
GSOC is officially scheduled to start tomorrow (my time), however I've take
the liberty of getting quite a jump on my work (as I described last week).
During this week I got the save using parameter and using queryset method,
these are fairly untested however. The reason for this was aft
ands for a --database flag, and
started removing various uses of the global connection object. I also got
the test harness more or less working with multi-db, however fixture loading
still only works with the primary DB, so any tests that rely on these will
fail if you have more than one database defined.
Hi Alex,
On Fri, May 8, 2009 at 16:04, Alex Gaynor wrote:
> Hello All,
>
> I've spent the past week at EuroDjangocon, and as such I've had the
> opportunity to discuss multi-db stuff with a bunch of very smart people.
> Simon and I resolved the issue of DSNs vs. di
Hello All,
I've spent the past week at EuroDjangocon, and as such I've had the
opportunity to discuss multi-db stuff with a bunch of very smart people.
Simon and I resolved the issue of DSNs vs. dicts (as long as Simon can
dynamically add a new DB he's happy). Otherwise noth
On May 2, 12:19 am, Malcolm Tredinnick
wrote:
> I'd prefer dictionaries to strings, because strings are tough to modify
> dynamically -- as has already been demonstrated a few times in Django's
> history.
That's a pretty strong argument in favour of dictionaries - in which
case it might be good
On Fri, 2009-05-01 at 08:47 -0700, codysacoder wrote:
> Why not allow both to work (parse the DSN string if encountered)?
That should be an option of last resort. One way to do things,
preferably obvious, even if you're not Dutch, and all that jazz.
I'd prefer dictionaries to strings, because st
Why not allow both to work (parse the DSN string if encountered)?
Something like...
DATABASES = {
'default': {'host': 'localhost', 'username': 'user',
'password': 'pass', 'database': 'production'},
'legacy': 'mysql://user:p...@localhost/legacy',
}
On May 1, 2:14 am, Mike Panchenk
I would agree with you on the dict issue, given that some of the
backends have custom settings etc. I also agree that this is not
really something that matters now - DSNs will need to be parsed into
dicts anyway, so you might as well implement the dicts first and then
see what the demand is for DS
Hi all,
Not a lot of new news or progress. I'll be at EuroDjangoCon all of next
week so I may be starting my work there, depending on the status of 1.1.
The only new news was Simon and I discussed switching to a DSN string in
place of the dict of settings. Personally I'm -1 on that as I find the
On Wed, Apr 29, 2009 at 8:24 PM, Simon Willison wrote:
>
> On Apr 30, 12:25 am, Alex Gaynor wrote:
> > My question would be how is using a DSN and letting those be passed
> directly
> > to using() any advantage over letting someone pass a dict of those
> options
> > to using(), or a connection ob
On Apr 30, 12:25 am, Alex Gaynor wrote:
> My question would be how is using a DSN and letting those be passed directly
> to using() any advantage over letting someone pass a dict of those options
> to using(), or a connection object itself.
No advantage at all - I'm interested in being able to h
On Wed, Apr 29, 2009 at 7:19 PM, Joey Wilhelm wrote:
> On Wed, Apr 29, 2009 at 16:03, Simon Willison wrote:
>
>> 3. (really nutty one this) - a very high scale situation where an
>> application is partitioned across hundreds of databases, which each
>> one having the same set of tables. This is h
On Wed, Apr 29, 2009 at 16:03, Simon Willison wrote:
> 3. (really nutty one this) - a very high scale situation where an
> application is partitioned across hundreds of databases, which each
> one having the same set of tables. This is how WordPress-MU works (as
> used by wordpress.com), with ever
On Apr 25, 7:11 am, Alex Gaynor wrote:
> Simon uses a new DSN based syntax for specifying DBs, however I find this
> pretty akward in the presence of our existing way for defining DB settings.
I had a few reasons for suggesting DSNs:
* We already use DSN-style syntax for cache backends - it's w
On Sat, Apr 25, 2009 at 2:21 AM, Richard S wrote:
> when done is this giong to be as simple as adding installed apps to one DB
> or the other?
>
> On Fri, Apr 24, 2009 at 11:11 PM, Alex Gaynor wrote:
>
>>
>>
>> On Sat, Apr 25, 2009 at 2:01 AM, Russell Keith-Magee <
>> freakboy3...@gmail.com> wrot
when done is this giong to be as simple as adding installed apps to one DB
or the other?
On Fri, Apr 24, 2009 at 11:11 PM, Alex Gaynor wrote:
>
>
> On Sat, Apr 25, 2009 at 2:01 AM, Russell Keith-Magee <
> freakboy3...@gmail.com> wrote:
>
>>
>> On Wed, Apr 22, 2009 at 1:45 AM, Alex Gaynor
>> wro
On Sat, Apr 25, 2009 at 2:01 AM, Russell Keith-Magee wrote:
>
> On Wed, Apr 22, 2009 at 1:45 AM, Alex Gaynor
> wrote:
> > Hello All,
> >
> > As you know by now I've been selected to work on multiple database
> support
> > in Django as a part of the Google Summer of Code. I'm going to try to
> k
1 - 100 of 147 matches
Mail list logo
