[...] > > - no serial/autoincrementing type, sequence + trigger required. > Using Oracle-specific initial SQL will be a workaround to get past that
bingo, thanks. > A more general solution should be possible, too, but will need a bit of > a redesign in management.py the backend creation.py files. Some kind of > hint being passed back that the field we are about to insert needs > fix-up work later and then post-creation call to the backend, for > example. That sounds good. This "initial SQL" trick is neat for DML (insert, update, delete), but seems like an unfortunate way to handle DDL (create, alter, drop, comment) that could also be derrived from the object model. > > - it's not OK to use 'long' for 'TextField', a table can only have one > > 'long' column - CLOBs required, kludging with varchar(4000) for the > > moment > > Somebody brought that up a while ago. That's a really bad Oracle-ism. > > It's going to take a bit of creativity to come up with a nice solution > there. I recon what's required is a special cursor encapsulates all that CLOB foolishness such that calling code can pretend it's a big text field. That way 'TextField' could map to CLOB, and nobody would have to know how unfortunate that was. By protection from variation, it would be tragic if anything outside backends.oracle had to do anything to accomodate CLOBs. db.backend.oracle.base.FormatStylePlaceholderCursor subclasses the cx_Oracle cursor. It already overloadeds the execute and executemany methods. Can you confirm that there would not be any calls to any other cursors? What if FormatStylePlaseholderCursor.execute<many>() 1. passed CLOBby SQL to the parent cursor as normal 2. inspected the columns 3 wrapped each CLOB colum in some sort of _read_CLOB_into_string() during the fetch. hey presto, it's as though CLOB columns hold big strings. > > - why is syncdb trying (and failing) to create tables that already > > exist? > > It sounds like _get_table_list() in management.py is not returning the > right information. That method is called to work out which tables have > already been installed so that they can be skipped. It calls a > backend-specific function to do the heavy lifting. That would be a good > first stop for debugging prints, I guess. Thanks, I'll look there next. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
