db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3576) Merge EngineBlob and EngineClob into a single interface
Date Sat, 29 Mar 2008 16:36:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583339#action_12583339
] 

Bryan Pendleton commented on DERBY-3576:
----------------------------------------

I have no objections to the patch as proposed, but am wondering: would there
be any benefit to handling this differently, by introducing a "EngineLargeObject"
interface from which both EngineBlob and EngineClob extend, and moving all
of the current content of both EngineBlob and EngineClob into EngineLargeObject?

That way, code such as you mention, which doesn't need to know the difference
between the two, could be simplified by just using EngineLargeObject, but
code (perhaps in the future) which needed to handle Clob differently than Blob
could still use one of the sub-interfaces.

Just thought I'd raise the possibility; as I said before I have no objections to the
proposal as stated.


> Merge EngineBlob and EngineClob into a single interface
> -------------------------------------------------------
>
>                 Key: DERBY-3576
>                 URL: https://issues.apache.org/jira/browse/DERBY-3576
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Network Server
>    Affects Versions: 10.4.0.0, 10.5.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>         Attachments: derby-3576-1a-enginelob_interface.diff, derby-3576-1a-enginelob_interface.stat
>
>
> There are currently two identical interfaces called EngineBlob and EngineClob.
> Merging these into a single interface would simplify some of the code handling Blob and
Clob in the network server, and it also allows a leaner implementation of a stored procedure
freeing LOB locators without knowing if the locator represents a Blob or a Clob.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message