Here's a patch against the current 0.5 trunk which I am going to add  
some test coverage for, feel free to try it out.   This will instruct  
the OracleBinary type to not read() the LOBs if the flag is set.   It  
makes no sense for it to do so otherwise.




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Index: lib/sqlalchemy/databases/oracle.py
===================================================================
--- lib/sqlalchemy/databases/oracle.py  (revision 5124)
+++ lib/sqlalchemy/databases/oracle.py  (working copy)
@@ -93,6 +93,9 @@
 
     def result_processor(self, dialect):
         super_process = super(OracleText, self).result_processor(dialect)
+        if not dialect.auto_convert_lobs:
+            return super_process
+
         lob = dialect.dbapi.LOB
         def process(value):
             if isinstance(value, lob):
@@ -123,6 +126,9 @@
         return None
 
     def result_processor(self, dialect):
+        if not dialect.auto_convert_lobs:
+            return None
+            
         lob = dialect.dbapi.LOB
         def process(value):
             if isinstance(value, lob):
Index: CHANGES
===================================================================
--- CHANGES     (revision 5124)
+++ CHANGES     (working copy)
@@ -33,6 +33,10 @@
       than strptime/strftime, to generically support
       pre-1900 dates, dates with microseconds.  [ticket:968]
 
+- oracle
+    - Setting the auto_convert_lobs flag to False on 
+      create_engine() will also instruct the OracleBinary type
+      to return the cx_oracle LOB object unchanged.
     
 0.5.0rc1
 ========


On Sep 25, 2008, at 3:09 PM, Michael Bayer wrote:

>
>
> On Sep 25, 2008, at 2:51 PM, Michael Bayer wrote:
>
>>
>>
>> On Sep 25, 2008, at 2:37 PM, MHC wrote:
>>
>>>
>>> Perhaps someone can comment on this question about Oracle BFILE's.
>>> (Oracle BFILE's are like BLOB's but the data is kept outside the
>>> database tables, in regular files on disk.  Each BFILE has a
>>> directory
>>> and filename entry in the table that points to the file on disk).
>>>
>>> SQLAlchemy handles BFILE's in the same way as BLOB's, and they work
>>> nicely, with one exception.  BFILE's have several methods that can  
>>> be
>>> called on the LOB handle, and there doesn't appear to be a way in
>>> SQLAlchemy that one can call these methods.  In particular it would
>>> be
>>> very useful to be able to call getfilename() and fileexists().   
>>> These
>>> are implemented in cx_Oracle, so the underlying facility is
>>> available.
>>> SQLAlchemy always gets the data with read() and returns  the  data.
>>>
>>> In the particular application I'm working on the user can upload
>>> various files to a database and these are stored as BFILE's.  The
>>> user
>>> can also browse through the database in various ways, and what he
>>> wants to see at first is the name of the file he uploaded (that is,
>>> from lob.getfilename()), rather than the contents of the file.
>>>
>>> Is there a way to call getfilename() on a BFILE column currently, or
>>> could that be implemented?
>
> sigh...I just checked the source, and i didn't quite finish the
> story.  The OracleBinary type is whats actually calling LOB.read()
> here.  auto_convert_lobs is the part which is invoking OracleBinary
> for all result sets, whether OracleBinary was specified or not.  But
> if you are in fact reading from a column that you've stated has a
> Binary type (either directly or via table reflection), its still going
> to LOB.read().   So you'd additionally have to forego the usage of the
> Binary type and use an agnostic type such as NullType to get the "raw"
> cx_oracle LOB object in those cases.
>
> putting on my thinking cap to see if theres a way to smooth this out,
> given that the unicode question from earlier in the day has some
> overlap here.
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google  
> Groups "sqlalchemy" group.
> To post to this group, send email to sqlalchemy@googlegroups.com
> To unsubscribe from this group, send email to [EMAIL PROTECTED]
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

Reply via email to