Re: Multi-DB Update

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

Re: Multi-DB Update

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

[GSOC] Multi-DB Update

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

[GSOC] Multi-DB Update

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

[GSOC] Multi-DB Update

Hey all, This past week unfortunately wasn't super eventful. I did some final dead code elimination on my m2m-refactor branch, I was able to kill about 150 additional lines of code that no longer needed, there are a few small changes I need to make to remove some quadratic behavior that occurs

[GSOC] Multi-DB Update

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

Re: Multi-DB Update

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

Re: Multi-DB Update

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

Re: Multi-DB Update

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

Re: [GSOC] Multi-DB Update

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

[GSOC] Multi-DB Update

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