Re: Java Class in Derby Table column?
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?
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 aforemention
Re: Java Class in Derby Table column?
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
Re: Java Class in Derby Table column?
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...
