Re: [Ejbca-develop] HardTokenProfileData and profile question

[Tomas G. <to...@pr...>]

The rationale is that if they are persisted in human readable form, is 
is at least theoretically possible to go in the database and read and 
change the information.
I dislike BLOBS for many reasons. One is that you can't see is it a 
regular database tool and the other is that BLOBS (or LONGS depending in 
database type) are often not handled well by the databases own tools. 
For instance in Oracle you can't replicate a LONG (at least that was the 
case a year ago) from the primary to a backup database (data warehouse). 
In a project I was working on we had to change (and split up) all longs 
to varchars for this reason.

This is different between different databases off-course, also in some 
cases it seems unavoidable (if a CRL is 1 MByte for instance, it's not 
really feasible to split is up in 4KB blocks for Oracle). But as long as 
possible I like to avoid BLOB/LONG.

For hsqldb I don't think you need to care really, since any datatype in 
hsqldb seems to be able to hold infinite number of bytes without 
complaining. All other databases are more restrictive. You never have to 
to anything special for hsqldb, only for all the other databases in my 
experience.

Cheers,
Tomas

Stephane Bailliez wrote:
> In HardTokenProfileDataBean (entity bean), the HardTokenProfile is 
> serialized into XML (UTF-8 encoded string) to be persisted.
> What is the rational behind this ?
> 
> I'm asking this question because we are doing a sql mapping in order for 
> this persisted field to be flexible according to the database and stored 
> as a blob (binary, bytea, image, .... depending on database)
> 
> This is a bit of a pain and we are forced to do the mapping by hand 
> while we could certainly rely on the container mapping if we simply say 
> that this data is a java object.
> 
> Basically I want to get rid of this (valid only for hsqldb):
> 
>    /**
>     * @ejb.persistence jdbc-type="BLOB" sql-type="VARBINARY(1100000)"
>     */
>    public abstract String getData();
>    public abstract void setData(String data);
> 
> In favor of:
> 
>    /**
>     * @ejb.persistence
>     */
>    public abstract Object getData();
>    public abstract void setData(Object data);
> 
> And remove the XML serialization.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop