I had purposely let this thread dangle, hoping Malcolm or Adrian or
Jacob might weigh in and decide the "db_tablespace" minor controversy.

But I hope this unresolved issue isn't perceived as holding up
integration of the Oracle patch.  I don't think it should.  At worst,
we could strip out the "db_tablespace" options altogether to simplify
the patch, then resurrect it as a separate patch on trunk once we know
which of the below options is preferred.  I also think it's ok to
leave it as-is for now.

So this is my "ping" to see if there's any general feedback on the
patch, and if there's any way we can facilitate it getting
incorporated.  Not a complaint!  [ducks head]

thanks,

Matt


On Apr 23, 7:21 pm, benk <[EMAIL PROTECTED]> wrote:
> Hi Matt,
>
> I can see where you are going regarding the manual "massaging" of
> "sqlall" output to create the database tables. My primary reason for
> the post was to ensure that I did not miss a piece of documentation
> showing how the tablespace could be set for other applications.
>
> To clear up potential misconceptions, I am most certainly not an
> Oracle DBA. Far from it. I am merely a lowly programmer who is
> currently working with Django.
>
> For the moment, I have worked around the issue of tables appearing in
> different tablespaces by creating an Oracle user configured to use a
> specific default tablespace which is the same as the db_tablespace.
> This means that for applications like auth where the db_tablespace is
> not specified, Oracle will create the table in my configured default
> tablespace. All of this of course happens at the user creation level
> in Oracle and makes the explicit setting of the db_tablespace option
> redundant.
>
> In my personal opinion (that I encourage those with higher powers to
> overrule as required) I think that it is leaving the db_tablespace
> option "as is" would be completely acceptable with the addition of a
> note to prevent misconceptions like mine. The only disadvantage that I
> can see with this path is that this option is a "halfway solution" as
> you put it and only applies to Oracle. This may lead to a longer term
> cluttering of the Django API for limited gain.
>
> Ben


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to