On Sun, 2008-10-05 at 17:59 +1100, Malcolm Tredinnick wrote:
>
> On Sat, 2008-10-04 at 23:49 -0700, Rock wrote:
> >
> > > In any case, you can already do what you want using custom managers. You
> > > return a custom queryset that generates the query however you like.
> > > Lifting all that up into Meta doesn't seem necessary to me.
> > >
> >
> > Good feedback Malcolm, but I don't understand that last statement. In
> > the case of partitioned tables for selected models, the model/manager
> > interaction with the database is unchanged from normal use accept that
> > there are some optimized options for batch deletion that a manger
> > class can add. However the main thing that is different in this
> > particular case is the creation of the tables and the creation of the
> > indexes. I was not aware that I could handle that with a custom
> > manager. (The way that I made this work was by creating a custom
> > version of the sqlreset manage.py command.)
> >
> > So how do I customize the table creation using the model manager?
>
> Aah, creation. Good point. You can't do that with a custom manager right
> now. That's something we'll have to solve with the multi-db stuff.
>
> I don't think it necessarily belongs in Meta, though, at least not as a
> pluggable storage engine type of thing. The reason is that I'm actually
> trying to move as much of the dependency on the fact that there's a
> relational database underneath away from the model-layer as possible.
> And "creation" is *very* specific to the type of backend. So once we
> have support for something like a Google App Engine storage backend or
> an LDAP storage backend or whatever, we still want to push that stuff
> into the storage layer, not have it in the models.
No doubt, I didn't explain my thinking here particularly well. I was
taking a walk just now and thinking about it some more, trying to work
out why I was uncomfortable with putting "more stuff" (whatever that
might be) in Meta. I think it comes down to this: how a model is created
at the lowest level ("create table" sort of stufF) is very much a
feature of the storage backend and each model is going to somehow have
to be able to specify a default database connection (which maps to a
storage backend by implication). Thus most creation stuff happens
automatically. In some cases -- such as where you need to create tables
in multiple databases -- there needs to be a way to call out to some
extra function in order to handle all this extra creation and that's
going to be very model specific (not storage backend specific).
Therefore a function hook is probably the right API for that situation
-- you can write whatever you like in Python.
It probably is appropriate for this extra function to be specific on
Meta (since it's meta-information about the model), but what the exact
API will look like is something I have no idea about and aren't going to
try and predict right now.
Maybe this is coming full circle back to what Rock proposed originally,
but it's not a plug-in database backend. I think that's too general.
It's a specific function that knows how to do the creation for cases
that are somewhat manageable. End of the day, though, for really complex
setups, it would likely be out of scope for Django to much of the
database creation management. That's stuff you do once (in effect). So a
hook, rather than a built-in solution is going to be a big part of a
pragmatic answer for these edge cases.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
