Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <4553CCC9.8070000@sbcglobal.net>
Date: Thu, 09 Nov 2006 16:50:17 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: (DERBY-378) implementing  import/export of large objects...
References: <45410499.808@gmail.com> <45478117.9010101@apache.org>
 <45491975.9090908@gmail.com> <454A4D7C.2010805@sbcglobal.net>
 <454A7105.60300@gmail.com> <454A7F1B.5050202@sbcglobal.net>
 <455125AC.20709@gmail.com>
In-Reply-To: <455125AC.20709@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Suresh Thalamati wrote:

> 
> Hi Mike ,
> 
> After thinking bit more about the cases you mentioned, better solution 
> might be to do write the binary data in HEX format when exporting the 
> data to only one file, instead of modifying the binary data with double 
> delimiters. This way main export file will be text file
> as it is now.
> 
> Only restriction with this approach is users can not use the hex number 
> (A-F , a-f, 0-9) as the delimiter; I think this restriction is 
> reasonable one.
> 
> If users required raw format , they can export binary data types to a 
> separate file using the new procedures.
I think the separate file approach is fine and resolves the most 
important blob import/export need.  It seems simpler, and likely to
be faster.

Doing hex for inline seems a reasonable alternative to messing with 
escaped delimiters in raw data.  I think the rest of the inline data
is always in some sort of "character" format.

If you only do one implementation I would think the separate file 
approach is better.

> 
> 
> 
> Thanks
> -suresh
> 
> 
> 
> 
>