You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Jim Crowell <Ji...@EMail.com> on 2009/05/08 20:52:57 UTC
Java Class in Derby Table column?
Hello,
I am developing a Java Stand Alone Application. Presently the data entered
is saved in HDD files of the host. Soon I will be changing the HDD files
structure to the Apache Derby Data Base. I am commencing to layout the Data
Base tables.
For my Address Book feature I have implemented a Java TreeMap component with
the following “Ordered Pairs”:
‘key’
Encoded String to uniquely identify the person name.
‘value’
A custom Java Class that contains the person’s control, contact info and
personal info. The contact info and personal info parameters are maintained
in their own custom Java Classes.
Question:
Basically I would like to place the Java TreeMap into a Derby table and
update just the appropriate “Ordered Pairs” as they are entered by my end
user. end.
Can I setup a 2 column table as follows:
‘Column 0’ The TreeMap ‘key’, i.e. the encoded person name.
‘Column 1’ The custom Java Class.
I am using Java 1.5x, Eclipse and Win XP Pro development platform.
I am also testing on a Mac OS X 10.5 [Leopard] node.
Regards,
Jim Crowell...
-----
Regards,
Jim...
--
View this message in context: http://www.nabble.com/Java-Class-in-Derby-Table-column--tp23451619p23451619.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.
Re: Java Class in Derby Table column?
Posted by Jim Crowell <Ji...@EMail.com>.
Rick,
> The major alternative to single-column storage is to use one of the
> object relational mapping frameworks like JPA. Apache has an
> object-relational mapping framework called Open JPA:
> http://openjpa.apache.org/ Many people on this list use Hibernate for
> shredding objects into tuples. This approach has some advantages over
> storing whole objects in columns:
>
> A) Incremental update. It can be significantly faster if you just need
> to update a small piece of a large object graph.
>
> B) Portability. Generally these frameworks are agnostic about what the
> underlying database is. That makes it easier to migrate your application
> from Derby to, say, Oracle or DB2 later on.
>
> C) Extensibility. The more granular the data, the easier it is to write
> new queries against it as your application evolves.
>
> D) Dependencies. The more granular the data, the easier it is to track
> and maintain dependencies among your objects.
>
I read up some more on the JPA, Hibernate, etc. you suggested.
I now have a cursory understanding of each.
I have decided that saving my jFormTK package class instances into the Derby
Data Base is not the way to go. I will use Derby to hold just the parameters
required to feed my report generator process and continue to save the
remaining data on the client side HDD in flat files.
As mentioned before in this thread, I already have hooks into my package
that I think will enable me to write the data to the Derby Data Base as each
form field looses focus. I am writing a similar process in my Address Book
class so that each revised field is written to the Data Base immediately.
I think that using JPA, Hibernate, etc. to achieve persistence would be
overkill for my package.
Thanks again for all the help.
-----
Regards,
Jim...
--
View this message in context: http://www.nabble.com/Java-Class-in-Derby-Table-column--tp23451619p23504535.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.
Re: Java Class in Derby Table column?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Jim,
Some responses inline...
Jim Crowell wrote:
> Rick,
>
>> You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA
>> column. You just have to write your own serialization logic to turn your
>> TreeMap into a byte[] and vice versa. Your table would look something
>> like this:
>>
>
>
>> create table AddressBook
>> (
>> encodedName varchar( 1000) primary key,
>> personalDetails varchar for bit data( 32672 )
>> )
>>
> Interesting, thanks.
>
> My Java stand alone project is a “Form Centric” Java kernel tool kit
> [jFormTK].
> The aforementioned Address Book is just an embedded Data Base of the JFormTK
> package.
>
> The JFormTK nucleus is the form field class [JFormField]. The package
> contains a set of Application forms [JFormForm] that host a set of fields.
> Each form has two classes to define the form specific information
> [JFormInfo] and state parameters [JFormForm].
>
> Presently all the above classes are stored in HDD flat files. To do so I
> have written ‘toString’ methods to convert the class parameters to delimited
> Strings. There are associated Java Constructors designed to instance the
> classes when reloading from the HDD.
>
> I believe this is akin to serialization marshalling and unmarshalling.
> Do you agree or am I missing something about Java serialization?
>
> If you agree, it would be an easy transition to convert my “Saved Strings”
> to an array of bytes.
>
If you can already serialize your objects to a string format, that's
great. You can store your objects in a "varchar" column instead of a
"varchar for bit data" column.
> One question about your sample table.
> Why “data(32672)?
> I know that 32,767 = 2 to the 14th and assume some linkage there to control
> the storage somehow?
>
You can also use the BLOB and CLOB data types if you need to store
really large objects (up to 2GB in size). However, the smaller datatypes
have some extra features:
1) You can index and sort on them. This can be useful if your serialized
form can be ordered or grouped in a meaningful way.
2) You can pass the serialized values to functions and procedures. This
can be useful if you want to use these columns in check constraints,
generated columns, and triggered procedures.
Right now, Derby does not let you sort BLOB/CLOBs or use them as
function arguments.
> One question about overhead?
> My JFormTK Kernel is a data entry system where, i believe, the time to read
> / write marshall / unmarshall to the HDD file system is miniscule compared
> to the data entry processing. I assume that the time to read / write
> marshall / unmarshall to a Derby Data Base will be the same or hopefully
> less than the current HDD implementation.
>
I don't see any extra overhead here other than the overhead which you
incur by using a transactional store rather than a flat file system.
> Before I received your reply I was investigating relational object Data
> Base’s such as JODB, MYOOP and DBn0. As stated above I believe I can afford
> the Derby overhead. However, I do not really need the SQL capability since
> I’ll primarily be emulating Java TreeMap’s in my Data Base implementation
> [similar to the Address Book example above].
>
I don't have experience with these products so I can't advise you here.
The major alternative to single-column storage is to use one of the
object relational mapping frameworks like JPA. Apache has an
object-relational mapping framework called Open JPA:
http://openjpa.apache.org/ Many people on this list use Hibernate for
shredding objects into tuples. This approach has some advantages over
storing whole objects in columns:
A) Incremental update. It can be significantly faster if you just need
to update a small piece of a large object graph.
B) Portability. Generally these frameworks are agnostic about what the
underlying database is. That makes it easier to migrate your application
from Derby to, say, Oracle or DB2 later on.
C) Extensibility. The more granular the data, the easier it is to write
new queries against it as your application evolves.
D) Dependencies. The more granular the data, the easier it is to track
and maintain dependencies among your objects.
Hope this is helpful,
-Rick
> I do not know about the maturity, footprint size and deployment capabilities
> of the above Object Data Base’s but I was wondering if any of the above Data
> Base’s would be a better fit for my situation.
>
> I really like Derby and would have to have a strong reason to go to an
> Object Data Base but I’m just trying to keep pace with whatever is out
> there!
>
> Another Object Data Base consideration should be my desire to eventually
> make this Java stand alone data entry processing "persistent". In my brief
> study of the above Object Data Base's, I saw that some seem to offer a
> persistence feature.
>
> I am somewhat of a control freak and I am thinking of doing my own
> "persistence" implementation. I already have hooks in JFormTK. Each time the
> end user enters a TAB or RETURN/ENTER key I am doing some processing. For
> the aforementioned Address Book, I could easily add key listeners to code
> persistent field processing.
>
> Any thoughts on 'persistence' in Derby OR the Object Data Base's would be
> appreciated.
>
> SORRY for the length of this response.
> I have a tendency to get to detailed sometimes trying to phrase a question.
>
> Many Thanks,
> Jim...
>
>
> Rick Hillegas-2 wrote:
>
>> Hi Jim,
>>
>> You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA
>> column. You just have to write your own serialization logic to turn your
>> TreeMap into a byte[] and vice versa. Your table would look something
>> like this:
>>
>> create table AddressBook
>> (
>> encodedName varchar( 1000) primary key,
>> personalDetails varchar for bit data( 32672 )
>> )
>>
>> Let me know if I'm being cryptic here. I'd be happy to explain this
>> solution in greater detail if you think it is useful.
>>
>> Hope this helps,
>> -Rick
>>
>> Jim Crowell wrote:
>>
>>> Hello,
>>> I am developing a Java Stand Alone Application. Presently the data
>>> entered
>>> is saved in HDD files of the host. Soon I will be changing the HDD files
>>> structure to the Apache Derby Data Base. I am commencing to layout the
>>> Data
>>> Base tables.
>>>
>>> For my Address Book feature I have implemented a Java TreeMap component
>>> with
>>> the following “Ordered Pairs”:
>>> ‘key’
>>> Encoded String to uniquely identify the person name.
>>> ‘value’
>>> A custom Java Class that contains the person’s control, contact info and
>>> personal info. The contact info and personal info parameters are
>>> maintained
>>> in their own custom Java Classes.
>>>
>>> Question:
>>> Basically I would like to place the Java TreeMap into a Derby table and
>>> update just the appropriate “Ordered Pairs” as they are entered by my end
>>> user. end.
>>>
>>> Can I setup a 2 column table as follows:
>>> ‘Column 0’ The TreeMap ‘key’, i.e. the encoded person name.
>>> ‘Column 1’ The custom Java Class.
>>>
>>> I am using Java 1.5x, Eclipse and Win XP Pro development platform.
>>> I am also testing on a Mac OS X 10.5 [Leopard] node.
>>>
>>> Regards,
>>> Jim Crowell...
>>>
>>> -----
>>> Regards,
>>> Jim...
>>>
>>>
>>
>>
>
>
> -----
> Regards,
> Jim...
>
Re: Java Class in Derby Table column?
Posted by Jim Crowell <Ji...@EMail.com>.
Rick,
> You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA
> column. You just have to write your own serialization logic to turn your
> TreeMap into a byte[] and vice versa. Your table would look something
> like this:
> create table AddressBook
> (
> encodedName varchar( 1000) primary key,
> personalDetails varchar for bit data( 32672 )
> )
Interesting, thanks.
My Java stand alone project is a “Form Centric” Java kernel tool kit
[jFormTK].
The aforementioned Address Book is just an embedded Data Base of the JFormTK
package.
The JFormTK nucleus is the form field class [JFormField]. The package
contains a set of Application forms [JFormForm] that host a set of fields.
Each form has two classes to define the form specific information
[JFormInfo] and state parameters [JFormForm].
Presently all the above classes are stored in HDD flat files. To do so I
have written ‘toString’ methods to convert the class parameters to delimited
Strings. There are associated Java Constructors designed to instance the
classes when reloading from the HDD.
I believe this is akin to serialization marshalling and unmarshalling.
Do you agree or am I missing something about Java serialization?
If you agree, it would be an easy transition to convert my “Saved Strings”
to an array of bytes.
One question about your sample table.
Why “data(32672)?
I know that 32,767 = 2 to the 14th and assume some linkage there to control
the storage somehow?
One question about overhead?
My JFormTK Kernel is a data entry system where, i believe, the time to read
/ write marshall / unmarshall to the HDD file system is miniscule compared
to the data entry processing. I assume that the time to read / write
marshall / unmarshall to a Derby Data Base will be the same or hopefully
less than the current HDD implementation.
Before I received your reply I was investigating relational object Data
Base’s such as JODB, MYOOP and DBn0. As stated above I believe I can afford
the Derby overhead. However, I do not really need the SQL capability since
I’ll primarily be emulating Java TreeMap’s in my Data Base implementation
[similar to the Address Book example above].
I do not know about the maturity, footprint size and deployment capabilities
of the above Object Data Base’s but I was wondering if any of the above Data
Base’s would be a better fit for my situation.
I really like Derby and would have to have a strong reason to go to an
Object Data Base but I’m just trying to keep pace with whatever is out
there!
Another Object Data Base consideration should be my desire to eventually
make this Java stand alone data entry processing "persistent". In my brief
study of the above Object Data Base's, I saw that some seem to offer a
persistence feature.
I am somewhat of a control freak and I am thinking of doing my own
"persistence" implementation. I already have hooks in JFormTK. Each time the
end user enters a TAB or RETURN/ENTER key I am doing some processing. For
the aforementioned Address Book, I could easily add key listeners to code
persistent field processing.
Any thoughts on 'persistence' in Derby OR the Object Data Base's would be
appreciated.
SORRY for the length of this response.
I have a tendency to get to detailed sometimes trying to phrase a question.
Many Thanks,
Jim...
Rick Hillegas-2 wrote:
>
> Hi Jim,
>
> You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA
> column. You just have to write your own serialization logic to turn your
> TreeMap into a byte[] and vice versa. Your table would look something
> like this:
>
> create table AddressBook
> (
> encodedName varchar( 1000) primary key,
> personalDetails varchar for bit data( 32672 )
> )
>
> Let me know if I'm being cryptic here. I'd be happy to explain this
> solution in greater detail if you think it is useful.
>
> Hope this helps,
> -Rick
>
> Jim Crowell wrote:
>> Hello,
>> I am developing a Java Stand Alone Application. Presently the data
>> entered
>> is saved in HDD files of the host. Soon I will be changing the HDD files
>> structure to the Apache Derby Data Base. I am commencing to layout the
>> Data
>> Base tables.
>>
>> For my Address Book feature I have implemented a Java TreeMap component
>> with
>> the following “Ordered Pairs”:
>> ‘key’
>> Encoded String to uniquely identify the person name.
>> ‘value’
>> A custom Java Class that contains the person’s control, contact info and
>> personal info. The contact info and personal info parameters are
>> maintained
>> in their own custom Java Classes.
>>
>> Question:
>> Basically I would like to place the Java TreeMap into a Derby table and
>> update just the appropriate “Ordered Pairs” as they are entered by my end
>> user. end.
>>
>> Can I setup a 2 column table as follows:
>> ‘Column 0’ The TreeMap ‘key’, i.e. the encoded person name.
>> ‘Column 1’ The custom Java Class.
>>
>> I am using Java 1.5x, Eclipse and Win XP Pro development platform.
>> I am also testing on a Mac OS X 10.5 [Leopard] node.
>>
>> Regards,
>> Jim Crowell...
>>
>> -----
>> Regards,
>> Jim...
>>
>
>
>
-----
Regards,
Jim...
--
View this message in context: http://www.nabble.com/Java-Class-in-Derby-Table-column--tp23451619p23461420.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.
Re: Java Class in Derby Table column?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Jim,
You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA
column. You just have to write your own serialization logic to turn your
TreeMap into a byte[] and vice versa. Your table would look something
like this:
create table AddressBook
(
encodedName varchar( 1000) primary key,
personalDetails varchar for bit data( 32672 )
)
Let me know if I'm being cryptic here. I'd be happy to explain this
solution in greater detail if you think it is useful.
Hope this helps,
-Rick
Jim Crowell wrote:
> Hello,
> I am developing a Java Stand Alone Application. Presently the data entered
> is saved in HDD files of the host. Soon I will be changing the HDD files
> structure to the Apache Derby Data Base. I am commencing to layout the Data
> Base tables.
>
> For my Address Book feature I have implemented a Java TreeMap component with
> the following “Ordered Pairs”:
> ‘key’
> Encoded String to uniquely identify the person name.
> ‘value’
> A custom Java Class that contains the person’s control, contact info and
> personal info. The contact info and personal info parameters are maintained
> in their own custom Java Classes.
>
> Question:
> Basically I would like to place the Java TreeMap into a Derby table and
> update just the appropriate “Ordered Pairs” as they are entered by my end
> user. end.
>
> Can I setup a 2 column table as follows:
> ‘Column 0’ The TreeMap ‘key’, i.e. the encoded person name.
> ‘Column 1’ The custom Java Class.
>
> I am using Java 1.5x, Eclipse and Win XP Pro development platform.
> I am also testing on a Mac OS X 10.5 [Leopard] node.
>
> Regards,
> Jim Crowell...
>
> -----
> Regards,
> Jim...
>