[EMAIL PROTECTED] wrote:
> perhaps we could put it all into backend/creation.py.
That's what i had, early, implemented with the firebird backend patch,
put the sequence and triggers sql in creation.py. And now i was trying
retain the management.py intact in terms of functionality, but your
aproa
Wiki page up:
http://code.djangoproject.com/wiki/MultipleDatabaseSupport
The current (sloppy, totally incomplete) patch is attached, along with
a description of where I see it heading.
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribe
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'll start working in that direction tomorrow, if that seems like a
> good plan. I'm going to be mostly internetless for the next 2 weeks or
> so, so it will be a while before I can actually submit a patch that's
> fully functional. But I c
> As I mentioned in another note to this thread, things are the way they
> are because I didn't want to load all the rarely-used reflection stuff
> into memory each time a model is used. That said, if it helps your
> goal (which would be a great Django addition), let's go ahead and make
> those mo
> And, in any case, they need to know the table name (and quite
> possibly database name and connection proxy) for the related tables. So
> you are going to have do a pass through all the models and build up the
> graph of dependencies and make that available to each model at
> construction time a
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'd argue that the right solution here would be to push the brains
> farther out to the edge. Have management functions call class methods
> on models to execute table creation, initial data loading, etc, rather
> than having them poll the
On Wed, 2006-06-07 at 22:25 +, [EMAIL PROTECTED] wrote:
[...]
> However, I've run into a problem that can't be fixed with little
> patches, in django.core.management. Specifically, all of the many
> get_sql_* functions in there pull together sql from multiple models and
> execute it all with
On 6/7/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'd argue that the right solution here would be to push the brains
> > farther out to the edge. Have management functions call class methods
> > on models to execute table creation, ini
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'd argue that the right solution here would be to push the brains
> farther out to the edge. Have management functions call class methods
> on models to execute table creation, initial data loading, etc, rather
> than having them poll the
I've been hacking away today at a patch for #1142 (multiple database
connection support), which is the last serious technical hurdle to my
company's use of django -- a very itchy itch for me to scratch.
Mostly things have gone well. My basic design is to add, as a
supplement to the current db.con
10 matches
Mail list logo
