On 5/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 5/4/07, benk <[EMAIL PROTECTED]> wrote:
> ...
> >
> > text length = 3998, saved length = 3998
> > text length = 3999, saved length = 3999
> > text length = 4000, saved length = 4000
> > text length = 4001, saved length = 2001
> > text leng
On 5/4/07, benk <[EMAIL PROTECTED]> wrote:
...
>
> text length = 3998, saved length = 3998
> text length = 3999, saved length = 3999
> text length = 4000, saved length = 4000
> text length = 4001, saved length = 2001
> text length = 4002, saved length = 2002
>
...
> Django on Linux + Oracle on Lin
Hi Everyone,
I have run into a curious problem while using TextFields (NCLOB
datatype) in the oracle branch.
The problem that I am having is that if I attempt to store a piece of
text greater than 4000 characters in length. The save function will
complete successfully however when I attempt extr
"Ian Kelly" <[EMAIL PROTECTED]> writes:
> It should drop the sequence at the time it drops the table. Have you
> been using the latest revision of the branch? There was an
> indentation bug I fixed a couple of weeks ago that was preventing
> sequences from being dropped under most circumstances
On 5/2/07, Jason F. McBrayer <[EMAIL PROTECTED]> wrote:
>
> Matt Boersma <[EMAIL PROTECTED]> writes:
>
> > 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]
>
> I'm doi
Matt Boersma <[EMAIL PROTECTED]> writes:
> 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]
I'm doing some testing here, and not really having any serious
problems. One
Hi Chris,
>From your description, it sounds to me like this would cause the query
to return a 4000-character varchar2 in place of the lob, and so the
domain objects returned by the Django distinct query would have their
TextFields truncated to 4000 characters. Silently returning truncated
data i
Ben/Ian/Matt,
re: SELECT DISTINCT LOBdata in Oracle
I have seen "select distinct myLOB" done in Oracle as "select distinct
first4kchar(myLOB)", where first4kchar() takes a LOB argument and
return's the first 4000 characters in a varchar2 type. Could dig up
the PL/SQL, ask me for it if you are in
Hi Ian,
Thanks for the response.
This isn't actually a show stopper for me, I was just logging the
issue as I stumbled across it.
Unfortunately I am not a Oracle expert so I don't have any useful
database level suggestions. My only thoughts with regards to Django is
that this issue/limitation sh
Hi Ben,
Unfortunately (or fortunately, depending on your point of view),
Oracle doesn't allow the DISTINCT keyword to be used when the SELECT
list includes a LOB column. Matt and I talked about this a couple of
weeks ago, but we couldn't see there being any good solution to the
problem, so we ju
Hi Everyone,
I think I may have found a bug with the way Django/Oracle is handling
NCLOB datatypes (used by TextFields) and the SELECT DISTINCT
statements. I have submitted a ticket (#4186).
Regards
--~--~-~--~~~---~--~~
You received this message because you are
Hello Michael:
> alter table in_wrong_place move tablespace new_tablespace;
> alter index in_wrong_place_ix rebuild tablespace new_index_tablespace;
>
In my office for example, politics and procedures indicate that before
creating Oracle tables, I must coordinate with DBA about the
definition of t
Hi All,
On 4/27/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hey Matt,
>
> On Thu, 2007-04-26 at 20:04 +, Matt Boersma wrote:
> > I had purposely let this thread dangle, hoping Malcolm or Adrian or
> > Jacob might weigh in and decide the "db_tablespace" minor controversy.
> >
> > But
Hey Matt,
On Thu, 2007-04-26 at 20:04 +, Matt Boersma wrote:
> 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
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 "d
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 potentia
Hello,
2007/4/23, Matt Boersma <[EMAIL PROTECTED]>:
[...]
> 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
-0, it may lead t
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 ar
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 t
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.djangoprojec
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
+1 on what Jim said, and since we are using this code in production at
Array BioPharma, we will stay on top of it. If you need an individual
point of contact, I can be that, and Ian Kelly and I will be
monitoring the mailing lists and Trac more actively and responding to
Oracle-related issues.
M
Jacob,
As we discussed at PyCon, we can make an even stronger commitment,
since this continues to be an official project for the Front Range
Pythoneers in Boulder. But people ultimately get this work done, so
kudos go to ring leader Matt Boersma, the intrepid Ian Kelly, Eric
Dobbs, Matt Drew, Mic
Hi guys,
Great work on the oracle stuff!! I've been using it with the multiple-db
branch for the last month or so and it's been great!
A couple of things I had to mess with (mainly to use introspect db):
- in django.core.management (line 842) I had to get my tables like this:
for table_nam
On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote:
> The "boulder-oracle-sprint" branch is ready to come home.
Wahoo!!
Just to clarify, Matt: you're willing to commit to maintaining Oracle
support once we merge this into trunk, yes? If so, I'm +1 on merging
this in (there's a few things we had
On Thu, 2007-04-19 at 22:38 +, Matt Boersma wrote:
> The "boulder-oracle-sprint" branch is ready to come home.
Nice work, guys. :-)
>
> We made a wiki page describing the goals and status of the code (quick
> summary: Oracle works and we think it's done, unless you tell us
> otherwise). At
The "boulder-oracle-sprint" branch is ready to come home.
We made a wiki page describing the goals and status of the code (quick
summary: Oracle works and we think it's done, unless you tell us
otherwise). Attached to that page is a patch against rev 5036 of the
trunk. See here:
http://code.dja
27 matches
Mail list logo
