Django developers Google Group

Re: Multi-credential ORM configuration support

2009-11-13T00:17:49Z

This sounds a little more dynamic that I was anticipating.

Multi-DB changes the way you define your database - instead of
DATABASE_HOST, DATABASE_NAME etc, you have a single DATABASES
dictionary, with each key-value pair representing a full database
configuration, including signin credentials. The process of actually

Re: Multi-credential ORM configuration support

2009-11-12T18:28:07Z

On Wed, Nov 11, 2009 at 5:08 PM, Russell Keith-Magee

So, if understand you correctly, with multi-db I could do the
following for each request:

1. Retrieve the credentials from the session.
2. Create a new, or update an existing, entry for those credentials in
the database configuration.
3. Somehow ensure that the using() operator is used on all ORM operations.

Re: Template Caching - Ticket #6262

2009-11-12T14:19:06Z

Hi Mike,

Thanks for the update. I'll do a detailed teardown over the next
couple of days and get back to you.

Yours,
Russ Magee %-)

Re: #7539 (ON DELETE support) aka ORM-09 - A call for feedback

2009-11-12T13:03:17Z

Am 11.11.2009 um 17:50 schrieb Michael Glassford:

Thanks a lot. I ran your tests with my patch. There were a few
(harmless) failing tests:
- sanity checks for SET_NULL on fields that are not nullable or
SET_DEFAULT on fields that have no default value. I moved the code to
model validation (and added tests there), so I just removed these tests.

Re: Template Caching - Ticket #6262

2009-11-12T01:18:46Z

As Mike said I've been reviewing this patch and I'm basically happy
with it's current state. My one thought was whether to add a
CACHE_TEMPLATE_LOADERS setting, and any loaders in that are cached by
the CachedLoader (assuming it's instantiated with no arguments, it'll
still be possible to explicitly instantiate it with loaders).

Template Caching - Ticket #6262

2009-11-12T01:15:38Z

Sup,

I've been working on template caching (ticket #6262) with a mister
Alex Gaynor. The patch is getting pretty stable and I think it's close
to merge-able, so if anyone wants to take a look at what we've got and
provide feedback: go!

Interesting background reading for people who haven't been part of

Re: Regularly-scheduled Django sprints, first December 11 - 13

2009-11-12T00:56:04Z

SVN is a sucky tool, but it really isn't the bottleneck in the
process. The bottleneck is deciding which one of a thousand patches I
(or any other member of core) should merge into trunk next.
Git (or any other DVCS for that matter) doesn't solve that problem. No
tool will - it's a social problem, and there's no such thing as a

Re: Multi-credential ORM configuration support

2009-11-12T00:08:45Z

You're pretty much correct. Django assumes that it has a single
trusted login to the database.
I can't think of an easy way - connection is essentially a singleton
in Django 1.1. However...
Multi-db allows you to set up multiple database credentials; the usual
reason for this is to split DB load across multiple database servers,

Re: ORM roadmap

2009-11-11T23:41:19Z

I'd agree and elaborate on #1, that ORMs are good for simple
object retrieval, and also for eliminating some of the most
grievous cross-platform issues.
However, I must disagree on #2 and #3: I'd never consider the
*addition* of a generalization-layer (an ORM in this case, but
the idea is far more broadly applicable) a step towards

Multi-credential ORM configuration support

2009-11-11T22:20:37Z

If this question would be more appropriate for django-users, please
let me know. I ask it here because I suspect that the answer to my
question may require someone with a fairly deep understanding of the
ORM internals.
I have a legacy oracle database that I would like to use with the
Django ORM. Unfortunately, the security for this database is

Re: Regularly-scheduled Django sprints, first December 11 - 13

2009-11-11T22:07:40Z

I'll keep an eye on your queue; I can easily push good patches from
there upstream to SVN.
If you stick patches into separate branches -- I suggest naming 'em
something like "trac/1234-short-ticket-desc" (where 1234 is the ticket
number) -- that'll make it easy for us Githeads to merge in ticket
fixes you post there.

Re: Regularly-scheduled Django sprints, first December 11 - 13

2009-11-11T21:57:02Z

On Nov 11, 1:57 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

Thank you, but no, I'm not enthused about git and GitHub per
se :) -- I'm enthused that it's possible to maintain patches
and collaborate remotely with less agony by utilizing them.

Please let's be friendly and relaxed -- I was just asking

Re: #7539 (ON DELETE support) aka ORM-09 - A call for feedback

2009-11-11T16:50:05Z

Oops, right you are. The unit tests were unintentionally omitted. I've
uploaded a new patch which is the pretty much the same as my previous
patch but with my unit tests included (although comparing the two now I
see a few other differences, probably because I also updated to the
latest code in SVN).

Re: Regularly-scheduled Django sprints, first December 11 - 13

2009-11-11T12:06:31Z

On behalf of the core team, I'd like to thank Jeremy for taking the
lead on this. Organizing an event like a sprint isn't glamourous work,
but it really helps the community, and it's an area where the core
team has been letting the community down. Thanks, Jeremy!
If there is any interest in an IRL sprint based in Perth, Western

Re: Regularly-scheduled Django sprints, first December 11 - 13

2009-11-11T11:57:30Z

Why do we need a central repository to coordinate a sprint effort? The
whole *point* using a DVCS is that you *don't* need a central
repository to coordinate activity.
Also - I know you're very enthused about Git and GitHub, but Django
uses SVN as the canonical store for trunk and branches, and this isn't