Re: [SQLObject] Oracle BLOBs and SOBLobCol, and metaclass interaction

[Ian B. <ia...@co...>]

Dmitry Cheryasov wrote:
> Ian Bicking =D0=C9=DB=C5=D4:
>=20
>> Dmitry Cheryasov wrote:
>>
>>> Hello.
>>>
>>> BLOBs and CLOBs as Oracle provides them have quite different=20
>>> semantics than strings. To accomodate this, I'd like to define an=20
>>> Oracle-specific subclass of [SO]BLOBCol and probably [SO]StringCol.
>>
>>
>>
>> What's the difference between a BLOB and a CLOB?  Do they act like=20
>> BLOBs on other databases?  It might make sense for CLOB columns=20
>> (whatever they are) to be activated by an option on BLOBs that only=20
>> Oracle pays attention to.
>=20
>=20
> CLOB is a character type (like TEXT in postgres), BLOB is a binary type.
> The main difference from 'normal' types is that actual retrieval of dat=
a=20
> (potentially quite huge) must be done explicitly, by a special call to =
a=20
> CLOB/BLOB object that the driver returns in the resultset. Whatever=20
> retrieval discipline would be, I need a way to call that clob.read()=20
> method to provide column value %)
>=20
>> There's no way to lazily load columns right now; that would be a nice=20
>> feature.  I'd call it "lazyLoad" instead of "demand_load".
>=20
>=20
> How much work (and where) would that take? I'm weighing my chances of=20
> participating.

Well, from what you say, it's really not necessary then -- SQLObject=20
will return the special object, and you can choose to read it or not.=20
This won't be portable across databases (other databases don't return=20
objects you read from), and implies that it should be a different column=20
type specific to Oracle.

Generally doing per-column lazy loading wouldn't be a lot of work, but=20
it's deep in SQLObject, so it's probably not a good place to get started.

If you wanted to just transparently load the data, regardless of whether=20
the users wants to use it, you could add a converter for the Oracle BLOB=20
type.  This would be done with the SOCol.createValidators() method.

For inserting BLOBs, I'm not sure; I get the impression that requires=20
database parameters to do on Oracle, that there's no literal syntax that=20
can be put in SQL.  Oleg is still working database parameter support in=20
a branch.

>>> If yes, how?
>>
>>
>> Thus the question: does SQLObject support the second approach, i.e.=20
>> database-specific column types?
>>
>> For each column type there are SQL create statements specific to the=20
>> database, so you overload those methods (e.g., oracleSQL()).  Those=20
>> really should be extracted so you don't have to edit col.py to do=20
>> this, but they aren't yet.
>=20
>=20
> Sorry, but I need to provide some specific *python* code for those pesk=
y=20
> clob/blob columns  :-\

If you look at col.SOBLOBCol, you'll notice it has a _postgresType,=20
_mysqlType, and a _mssqlType.  You'd add a _oracleType, and also that=20
method to SOCol, SOStringCol, etc.

>>> What I probably need is the metaclass to retrieve right column=20
>>> classes from the database adapter when a descendeant of SQLObject is=20
>>> being created.
>>
>>
>>
>> Because the database backend is not necessarily known at the time the=20
>> SQLObject class is created, this is not possible.  But there's a=20
>> couple ways to handle database-specific funkiness, so it should be=20
>> possible somehow.
>=20
>=20
> OK, I'll stick to database-specific column types for now, in hope that=20
> the code could be reused in the future. Too bad I'll need to poison=20
> col.py with utterly oracle-specific code.

Yeah, that's just the way it works now for all databases, so don't worry=20
too much about it.  Are you working off the trunk, the 0.6.1-oracle=20
branch, or...?  I'd like to keep all the Oracle work synchronized=20
between the people doing it.


--=20
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org