That's a good point, Ben. There isn't any way to propagate the db_tablespace parameter back to models not directly under your control, like auth, sessions, etc., so the db_tablespace parameter we added is only a halfway solution.
Our thinking was that for any "real" Oracle deployment, chances are high that you'll want to take the output of "./manage.py sqlall" and at least modify the index and row tablespaces, as well as create more specific grant permissions (and change LOBs to be stored out-of-table, and...). We are unlikely to please a full-time Oracle DBA with the DDL we create no matter what we do, given the richness of Oracle's storage options. Having the db_tablespace parameter makes at least the models under your control more self-documenting. But it's not perfect. Here are the three options I can think of: - Leave as-is, realizing it helps somewhat - Drop the "db_tablespace" and index tablespace keywords altogether to avoid this confusion - Add a mechanism for a default global tablespace and global index tablespace that apply unless overridden in a specific model or column Thoughts? Matt On Apr 22, 10:02 pm, benk <[EMAIL PROTECTED]> wrote: > Hi, > > I have been using the Oracle branch now for a few months and it is > looking really good. > > I have a question regarding the use of the 'db_tablespace' option in > the Meta class. I am able to set this option within my application and > successfully perform a syncdb that will place all my tables in the > correct tablespace. The question/issue that I am having is that I > cannot see a way of instructing any other application (such as > authentication) to also create its tables in the tablespace of my > choosing. > > To my understanding the application will either create its tables in > the tablespace specified in its own models.py or it create its tables > in whatever the default tablespace happens to be. This results in > tables being created in several different tablespaces. > > For my 2c worth, if this cannot already be done by the current Oracle > database framework, I think that would be a beneficial addition if > only to provide completeness to the option to assign tablespaces. > > Regards > Ben Khoo > > On Apr 21, 1:54 am, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > Ben Khoo already found a good bug (#4093) that we fixed, and in the > > process we found a problem we'd created for Postgres that wasn't > > caught by any of the tests. So we fixed that and added a "datatypes" > > test to modeltests. > > > So there is a slightly newer patch available > > now:http://code.djangoproject.com/attachment/wiki/OracleBranch/django-ora... > > > We'll try not to do this again so people can focus on the content of > > the patch for a bit, but these two things needed to be fixed ASAP. If > > you're testing the boulder-oracle-sprint branch directly, please > > update. > > > Matt > > > On Apr 20, 10:03 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > > > > On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > > > The "boulder-oracle-sprint" branch is ready to come home. > > > > Congrats, guys! Thanks to all of you for your hard work. I'm +1 for > > > merging it, too, once we've taken a look at it. > > > > Let's organize the merge process. Malcolm, since you've been dealing > > > with query.py and other databasey parts of Django, do you want to take > > > the lead on the merge? Or Jacob? I could get to it next week if you > > > guys are busy. > > > > Adrian > > > > -- > > > Adrian Holovaty > > > holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
