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
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
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
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 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
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
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
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
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
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
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
11 matches
Mail list logo