JDO experience of a New York female technician
JDO Application Introduction by TERESA LAU Translated from: http://www.sys-con.com/java/ArticlePrint.cfm? Id = 1899 (Translator Note) This article takes an actual class structure instance and Kodojdo Product basis, introduce the principle, use and characteristics of JDO. In particular, comparison with traditional JDBC technology, such as a class of code to decrease from 480 rows to 140 rows, indicating that JDO is reduced to code. In addition, the author of this article is a female Zhonghajie with more than five years of Java consultant, with a master's degree, currently working in New York. Java Data Object (JDO) is a standardized API for accessing objects in some data warehouse. It is a highly ease of use and flexibility to make JDO from various data object access technologies. JDO provides transparent object storage, so that the developer does not require additional code (such as the JDBC API). These cumbersome routines have been transferred to the JDO product provider, so that developers are freed out to concentrate on time and energy logically. In addition, JDO is flexible because it can run on any data underlayer. JDBC is just a relational database (RDBMS DO is more common, providing storage features of any data underlying, such as relational database, file, xml, and object database (ODBMS), etc., make it stronger to apply portability. Overview Descriptor (Enhancer) and Enhancer In JDO, any class that needs to be stored must be PersistenceCapable, and any other classes that use these classes must be PersistenceAware (storeless). It looks a bit complicated. However, good news is to use JDO transparent storage technology, you don't need to implement your classes in your code or PersistenceaWare interface. You only need to write a class in us, JDO vendors will provide one. Enhancer, this enhancer will transform your class code (translator Note: It is .class file, binary code in transformation Class is not a very deep thing, there are many tools to provide you to transform the class file, For example, when a method starts and ends at the end), according to your descriptor to implement the persistencecapable interface. The only additional job you need to do is to write an XML format descriptor file for the store you need to store. Attachment 1 shows a descriptor file I use in the later code demonstration. (Annex 17 and this document can be downloaded at www.sys-com.com/java/sourcec.cfm.) Descriptor General Very short, it is not difficult to write under the default condition. JDO has been gains a lot of information from the class itself. You only add additional information in the descriptor in the following case:. You need to change the default operation of JDO, such as Make an attribute without depositing the database, even if it is not marked as transient. Some additional information is JDO unable to be obtained from the class itself, such as: which property you want to be set to the primary key in the database (Translator Note: Only make Application Identity has this necessary), or the element in a collection type (Collection or sub-interface / class) is what type of storage manager (PersistenceManager) When your class is enhanced, you may use PersistenceManager to store you. Object.
To get a PersistenceManager, first set some properties, usually include the following information:. Database connection information. JDO product class name. The default attribute, including connecting pool size, etc. Attachment 3, line 23 shows how to set up a Properties object, get a JDO's PersistenceManagerFactory (equivalent to DataSource in the JDBC connection pool), and get a PersistenceManager object (equivalent to The connection object in JDBC), then you can use this PersistenceManager object to add, update, delete, query objects (this is also what I will discuss later). When your operations are finished, you need to close the primary PersistenceManager object to release it to make it again (such as another thread). The code snippet of attachment 3 tells you if you use JDO to store and query objects. With a PersistenceManager type object PM, you can use the PM.MakePersistent () method to save a new object to the database (line 68). An object only needs to be saved to the database in the first time (the translator's note: more strict, only when there is no stored object reference, it needs to be explicitly calling the MakePersistent () method), when it is already in the database After existence, the information of the object can be updated directly by accessing its properties. All updates are saved in the current Transaction (Database Concept: Transaction). And if you don't want to save the main changes, you only need to simply Rollback Current Transaction (15 to 17 lines). Similarly, you can call PM.DeletePersistent () to delete an object (line 26). To access the already stored object, you can simply traverse its extent (all extensions of the class), which is a logical general title for this class object (line 12 to 15). If you want to selectively (not an ancient brain) to remove a subset of all objects of a class, you can create a Query. To do this, call PM.newQuery () to get a query object and pass it into parameters: candidate object set and a filter. The candidate object set can be a collection or a class of Extent. The filter is a JDOQL (JDO Query Language) statement. Once you have created this Query, you can perform it to get a collection of qualified collections (Collection, lines 22 to 26). JDOQL is a Query language of JDO; it has a bit like SQL, but it is in accordance with Java's grammar. The example here is just a simple demonstration; use JDOQL, your filter stroke can be written complicated. Also, if you use the binding parameters in the filter string, you can write a simple query and then do many times, each time you give a new parameter value. About JDOQL has a lot of information for reference, see the list of resources in this article. An example of an object store To find whether the JDO is like SUN, I will write some code, using JDO and JDBC to store the Book object I created (see Annex 4). This book object has a Name property and a block object.
In order to make the example interesting, the Book object has a limit: each book is unique to its name, that is, you can't join the books of the same name. A block (block) is an components of the book, which can be Document, Chapter, or Section. The topmost Block is the Document type and can include any number of Chaptor Blocks. Each Chaptor Block can include any number of SETInd blocks, so there is a nesting relationship in these blocks. In each block, we use a HashMap to store any number of other BLOCK key value pairs. Attachment 5 lists a book for testing in my example. This book consists of two chapters. The first chapter has a section, and there is a second chapter. In particular, the second chapter has an attribute: color = red. With this book example, I want to implement one of the following storage features:. Add: See if I have successfully added two books to the database, and if I use the same name to join the third book, I will generate an exception that the uniqueness check failed. Update: See if I can update a book: Add an attribute "comment" to its root block. When I submit (commit), these updates should be saved, and if I roll back, these updates will be discarded. . Delete: See if you can query a book through Query and then delete it from the database. If there is no JDO, I usually design: firstly design a few related relational data sheets to store data in the bory, then use SQL and JDBC to store / read these tables. Due to the relationship between the length, I will not list my JDBC implementation here, but if you are interested, you can download it from the JDJ website. Note that in order to implement the above functions through JDBC / SQL, I must write a long code (480 lines!). What I have to do now is to let you see how simple is the same feature in JDO. Store a Book object with JDO to store a BOOK object, although I use the same BOOK primary key class in the JDBC mode, but the iD attribute of Block is completely unnecessary. In the JDBC mode, you must use the ID attribute to separately reference the different blocks in the data table. But in JDO, I don't need this attribute at all because JDO will automatically process it under the bottom. To indicate that the Book object is required, I wrote a descriptor to mark the Book and the Block class (see Annex 1). In the descriptor, I indicate that the element type is Block (10th to 11th line), and the type of HashMap is String (line 12 to 14) of the type of CHildren collection attribute. In addition, since the ID attribute is not a block truly needed, I labeled it in the descriptor that it does not need to be stored (line 8). In the descriptor tablet of the book, I indicate that the NM (Name) property is its primary key (line 5), so the Book class requires the use of custom identity types (Application Identity), class name is BookKey. The code of the bookKey class is shown in Annex 6. In this example, the JDO product I use is Kodojdo (using the relational database as the bottom layer).
There are many JDO products on the market; you can choose any of them, and your code does not need to make any changes. The underlying relational database I select ENHYDA Instantdb (a relational database with KODO products). The essence of JDO is that developers don't need to know how a JDO product is stored in the database, so I don't need to design any data sheets, although our underlying is related database. Kodo offers a tool called Schematool, which automatically creates a required data table structure based on my descriptor. All things I need to do are to run the following commands to prepare the bottom of the database (the translator Note: In fact, Kodojdo2.4.0 or higher can complete the automatic database synchronization, this step can be omitted. But it is recommended to use it when developed : Schematool Action Refresh Bookschematool Action Refresh Block Next I normally compile my class, then use KODO's enhancer, named JDOC, to enhance my class code (Translator Note: These steps can be Ant batch Treatment tools are completed, most JDO vendors provide ANT task support): JDOC Bookjdoc Blockjdoc Bookpersistjdo here, as long as I will not enhance the Class file (Book.class, BlockPersist.class, bookpersistjdo.class), and descriptors to JDOC If you find the location, JDOC will change these class code so that it becomes AsstenceCapable, without marking the stored classes will be enhanced as PersistenceaWare. In this example, book.class and block.class are transformed into PersistenceCapable, while BookPersistjdo.class will be transformed into PersistenceaWare. (Translator Note: You need to explain that many opinions advocate non-stored classes only through the accessor (Accessors, TET / IS methods) to access the properties of the stored objects, which, these non-stored classes are not It needs to be enhanced to reduce complexity.) After these classes, any work that operates to me can be done by PersistenceManager. With the code you mentioned earlier, I can get a PersistenceManager PM very simple, then use it to increase, delete, and update a book. Attachment 7 shows the code snippet of my BookPersistjdo.java. The method of the ADDBOOK (line 3) demonstrates how I add a book through JDO, while Deletebook (line 13) demonstrates how I delete a book. Take a book through the name, I created a Query using the JDOQL filter. After performing this query, I got a collection (25th to 29 lines). After getting a Book object, I directly change its properties and submit it. Annex 3 shows the test results of the example of my JDO mode. The result is in line with my expectations. First, I successfully joined the book to the database, and then added another book of the same name, and the result produced a JDOUSEREXCEPTION, telling me rules that violate the uniqueness of the name.
Then I can update the information of a book, submit these updates, or give up these updates by rolling. Finally, I can find a book from the database, then delete it. Two versions of comparisons (JDBC VS JDO) Solve the same problem by using JDO and JDBC, I observe the following: 1. If you use JDO, I can do the same thing as JDBC. I can query the object through jdoql; guarantee the name uniqueness of the book by marking the NM property of the Book class; additional, delete, update these objects. 2, JDO makes my transaction more easily. In JDBC mode, because a book is actually corresponding to many records in four different relational data tables, I must ensure that all insert and deletions are completed in the same transaction. Instead, JDO can only save all of these changes only, and I don't need to use Transaction to maintain the atomicity of this operation. 3, bookpersistjdo.java is only 140 lines, there are many more than bookpersistjdbc.java (480 lines), which means that JDO makes my code much less. In particular, the relationship between my classes has nested features makes the table structure in the relational database is more complicated. In my JDBC implementation, I have to spend a lot of mind to design my database to store and get these nested data. I have to use an ID field to represent each block and use a foreign key to express the parent / sub-relations. In JDO implementation, I don't need to consider these issues at all, everything is stored correctly. 4. In order to improve performance, the buffer mechanism added in JDBC implementation is not needed in JDO, as JDO products generally contain performance optimization and buffering. These also save me a lot of workload, because I don't need to worry about whether my buffer is always synchronized with the database. In addition to these differences, JDO products and my JDBC implementation may not have much difference. For example, this JDO product uses a relational database, which may also use a similar table structure design and ID generation mechanism, and store data with JDBC. However, the key is that I don't need to understand the details of these implementations: These burdens are transferred to JDO vendors with professionals, and these people are more likely to do better on these details. Additionally, these vendors can also choose to store in other types of storage technologies, such as object databases or files, etc., which give us a lot of flexibility in choosing specific storage methods. Conclusion JDO provides a lot of benefits:. It has all required data storage features: increase, delete, change, transaction, uniqueness, buffering. It eliminates the need for a lot of cumbersome work in developers to make the code more easy to read and maintain. It is independent of specific manufacturers to prevent manufacturers from dependence. Although my code is not displayed, it can work in any data warehouse to make the development flexible and portable JDO is a value-drilled technology. This article is just a starting point; more information, please see the following resources. Resources. One-stop website: http://www.jdocentral.com/. Specification: http://access1.sun.com/jdo/. ROOS, R. (2002). Addison Wesley Press: http://www.ogilviepartners.com (Translator Note, I have the book author to give me the PDF version, you can share it with everyone, but don't Business use).
This article uses JDO products: Solarmetric: http://www.solarmetric.com/software/kodo_jdo (Translator Note: Kodojdo is the best product, performance is very optimized, especially the latest 2.5. 0Beta version. The development team of this product is basically coming from MIT. Kodojdo's current disadvantage is that it is not like Hemisphere, South Africa, and has an independent descriptor editing tool, which can only be used above JBuilder7. Under my suggestion, they are ready to add such a tool in version 3.0.) JDO's Properties Configuration Attachment 2 provides the properties file I used later. I used a relational database that contains information about the database connection. Chain 6 contains the class name of the JDO product I use (the translator's note: the manufacturer's implementation class for the PersistenceManagerFactory). The 8th to 10 lines are the default settings for the PersistenceManager, indicating that I use Optimistic Transaction, and the data can be restored from the buffer when Rollback, and these values are not retained when submitted (the translator Note: the purpose is to ensure that the trigger in some databases The resulting update can be read back from the database). There are still many details that can be used to use which options when transaction are performed. Please read the JDO API to find their meaning and use it when you need it. JDBC implementation here I simply describe how I use the JDBC to store the Book class. After you know how much work is included, you will more understand everything that JDO is what you do. I created four tables to store BOOK (see Figure 1). To ensure data uniqueness, the NM field of the BOOK table is marked as a single index (the translator's note: actually labeled the primary key). To track the properties of each block and its subset, I add a blockID field for each Block. This blockID field is generated when each block is added to the database (add 1 on the basis of the BlockID value in the largest block table already existing). Increasing a book involves breaking down the information of a BOOK object into four tables: Book, Block, BlockRelation, and blockattr. In particular, each block needs to generate a blockID. Further, the most troublesome is that Blocks is nesting / recursive, and I must write the recursive code to insert these data into the database. In Annex 5 Create an example of creating books, these data tables are displayed in FIG. You can see that a book is converted into a lot of rows in four tables, so all inserts must be packaged in a transaction, so that a book will be added or completely canceled, never incomplete. Similarly, deleting a book involves identifying all the right rows that need to be deleted from the four tables and removed in a transaction to ensure that this book is completely deleted or canceled. In order to better performance, I don't want to take the data from four tables every time someone needs to query a book. I created a Bookcache, and when I started running, I took out all the books from the database. When I increase, delete, update these books, my code guarantees that Bookcache is synchronized with the database. All of this work is completed in this cache, making it a book to look up in cache in Cache. There are still these advantages that are not perfect, and there are still some places to do not enough:. It is very good for newly developed projects, but if you want to use the existing relationship database to use JDO, you need to do some mapping work (edit the descriptor).
For developers, after using JDO, we no longer need to handle the underlying database access, so it may be more difficult to performance optimization. Because JDO must do a lot of additional work, such as tracking object properties, how to synchronize internal buffer, etc., how JDO products do is critical. JDOQL does not support aggregation operations, such as Max, Min, SUM these SQL can do. (Translator Note: Chapter 24 of JDO1.0 specification details the next 2.0 specification should do, which contains these). If you can find a JDOQL error when you compile. For example, in a filter string, you can specify a property name through a string, you can easily write the wrong name, but compile will not be wrong, run when running. (Translator Note: SQL also has the same problem). Some people think that JDO is that you don't need to write SQL, but the real situation is that you must learn JDOQL. Author's introduction Teresa Lau has been more than five years as an independent Java consultant, focusing on financial systems. She has a master's degree in computer and is currently working in New York.
Source code: Listing 1 metadata for my eXample1 2
PM.Getextent (MyClass.class, false); 13 for (Iterator i = ext.iterator (); I.hasnext ();) {14 myclass obj = (myclass) i.next (); 15 obj.setfield1 (" AA "); 16} 17 pm.currentTransAction (). Commit (); 181920 // --- Query and delete --- 21 pm.currenttransaction (). Begin (); 22 string filter =" nm = / "jdo Book / ""; 23 query = pm.newQuery (ext, filter); 24 Collection c = (color) qry.execute (); 25 Object obj = c.iterator (). Next (); 26 pm.deletepersistent Obj); 27 pm.currentTransAction (). Commit (); 2839 // --- Close Resources --- 30 pm.close (); Listing 4 Book & Block Object1 Class Book {2 string nm; 3 block block = new Block ("document"); 45 book (String name) {6 this.nm = name; 7} 89 Void AddChild (block e) {10 block.addchild (e); 11} 12} 1314 Class block {15 string Type 16 Integer ID; 17 Map attributes = new hashmap (); 18 list children = new arraylist (); 19 20 block (string type) {21 this.type = type; 22} 23 24 Void AddChild (block e) {25 Children.Add (e); 26} 27 28 Void SetaTRIBUTE (String Key, String Attr) {29 Attributes.PUT Key, Attr); 30} 31} Listing 5 Create Test Book1 Book Book = New Book ("Intro TO JDO"); 2 Block Chp1 = New Block ("Overview", "Chapter"); 3 block second1 = new block ( "Advantage Of JDO", "Section"); 4 chp1.addchild (Sec11); 5 block chp2 = new block ("eXample", "chapter"); 6 Chp2.SetaTRibute ("color", "red"); 7 Block Sec21 = New Block ("JDBC Code", "Section"); 8 Block Sec22 = New Block ("JDO Code", "Section"); 9 Chp2.Addchild (SEC21); 10 Chp2.Addchild (SEC22); 11 Book.addchild (chp1); 12 book.addchild (chp2);
Listing 6 bookkey.java1 public final class bookkey {2 public string nm = null; 3 public bookKey () {} 45 public bookKey (String nm) {6 this.nm = nm; 7} 89 public boolean equals (Object O) { 10 IF (o == this) Return True; 11 IF (! ") Return False; 12 return ((BookKey) .nm.equals (nm); 13} 1415 public int 6code () {16 return nm.hashCode (); 17} 1819 public String toString () {20 return nm; 21} 22} Listing 7 BookPersistJDO.java1 class BookPersistJDO {23 public Book addBook (Book book) 4 throws JDOUserException {5 PersistenceManager pm = getPM ( 6 Transaction Tran = PM.CurrentTransAction (); 7 Tran.Begin (); 8 PM.MakePersistent (Book); 9 Tran.commit (); 10 Return Book; 11} 12 13 public void deletebook (book book) { 14 PersistenceManager PM = getpm (); 15 Transaction Tran = PM.CurrentTransAction (); 16 Tran.Begin (); 17 PM.DeletePersistent (Book); 18 Tran.Commit (); 19} 1415 Public Collection getAllBooks () {15 PersistenceManager PM = getpm (); 17 string filter = ""; 18 extent extent = pm.getextent (bo Ok.class, false; 19 query = pm.newquery (extent, filter); 20 return (Collection) qry.execute (); 21} 2223 public book getBook (String name) {24 persistenceManager PM = getPM (); 25 string filter = "nm == /" " Name " / ""; 26 extent extent = pm.getextent (book.class, false); 27 query = pm.newquery (extent, filter); 28 Collection C = (Collection) qry.execute (); 29 return () c.iterator (). Next (); 30} 31} Additional code for this article zip file ~ 7.78 kB Figure 1 Figure 2 Figure 3 User Review JDO Not vendor independent posted by Scott P. Smith on Mar 4 @ 01:27 Pm A Few Weeks Ago, I Attended a One Hour Talk by Oracle '
s Director of Technology, Donald Smith covering persistence archetectures. In it he strongly stated that JDO is not completely vender independent. I do not know that myself. I'm just repeating what he said, which conflicts with claims made in this article. (Read & Respond ...) ------------------------------------------ -------------------------------------- Author lacks jdbc knowledge posted by Donald Bales on Mar 4 @ @ @ @ @ @ @ @ @ @ --- 07:39 PM The whole article became tainted when the author stated: "... JDBC provides persistence only for relational databases ..." Not true JDBC can handle most of the data sources listed In fact, many JDO implementations utilize JDBC.. "under the covers". Second, JDO claims to be able to support these other data sources, but I do not see many implementations. JDO provides a slick abstration for relational databases, but it's not the silver bullet that it's hyped to be. (Read & Respond ...) ------------------------------------------ -------------------------------------- JDO NOT VEN dor Independant Posted by I Davie on Mar 5 @ 04:51 AM JDO is meant to be a Java standard not a database standard. Oracle are not interested in JDO because it gives developers choice and Oracle do not like that! If they're Forced to move what way... -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------- --Pro-JDO Comments from JDO Vendors Posted by Scott P. Smith ON Mar 5 @ 10:12 Am Another Thing That Donald Smith (No RELATION) from Oracle Said Was That The Only People Making Positive Comments About JDO Are JDO Vendors. I See "I Davie"
IS with Versant, Which Is Soon to Be a JDO Vendor According to Their Web Site. I am Very Neutral Used It. Can We Hear Comments from Somene (WHOESN (Read & Respond ...) -------------------------------------------------- ------------------------------ JDO Posted by Bret On Mar 9 @ 11:22 PM http://www.sys- Con.com/java/Article.cfm?id=1899 (Read & Respond ...) ----------------------------- -------------------------------------------------- -Anti-JDO comments Posted by David Tinker on Mar 14 @ 08:26 AM Treat anything that anyone associated with Oracle has to say about JDO with caution. Oracle own Toplink, a $ 10K / CPU O / R mapping tool that competes directly with JDO. If JDO is sucessful who will pay that kind of money for vendor-lock-in O / R mapping? The most expensive JDO implementations are approx $ 3K with no runtime costs.I will not say anything about JDO as I work on JDO Genie from Hemisphere Technologies :) Try it for yourself! (Read & respond ...) ----------------- -------------------------------------------------- ------------- Non-vendor Comment Posted by Chester Arnold on Mar 24 @ 07:49 AM I Agree with David Tinker. You need to learn to try Things out and not always believe Vendors Who Are trying to salvage tanking stock prices. I've used a number of JDO implementations including the one the article used (Kodo JDO). The quality of JDO implementations vary widely so trying them out is probably the best thing you can do.You can find A List of JDO Implementations at www.jdocentral.com. (Read & Respond ...) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------- Oracle Fear !! Posted by Alf On Mar 25 @
