Hi Jeff, I completed the new JPA based SimpleScheduler DAO implementation. Now there is JDBC based implementation (refactored original delegate implementation), a JPA OpenJPA implementation (default now), and a JPA Hibernate implementation. I did not create a new non-JPA Hibernate implementation since to my knowledge JPA will be the persistence implementation of choice for ODE.
One last think that needs to be done is to update the JPA DDL module to include additional indexes in case the SQL generator does not index everything that needs them. Also as part of my refactoring I added transactional operations to the DAOConnection interface so that it can hide the underlying transactional mechanism in case JTA is not used. To me it makes the DAO usage more concise. Perhaps in the future the engine and runtime code can be modified to utilize the DAO transactional operations instead of directly manipulating the JTA transaction manager. Please take a look and let me know what more needs to be done for the JPA refactoring effort. Regards, Aaron ________________________________ From: Jeff Yu <jeff.yuch...@gmail.com> To: dev@ode.apache.org Sent: Tue, March 16, 2010 10:29:33 PM Subject: Re: JPA DAO refactoring. Hi Aaron, I just did a quick run with the latest change, all modules compiled successfully, didn't get chance to run the test case. Unfortunately, I will be on vacation in the rest of this week, won't get time to look into the code until next week. please feel free to add the jpa impl for scheduler. Thanks for this great work. ;) Regards Jeff On Tue, Mar 16, 2010 at 10:13 PM, Aaron Anderson <aaronander...@acm.org>wrote: > Hi Jeff, > > I updated the github JPA branch again with some changes so that the branch > now compiles with JDK 1.5 and utilizes H2 as the embedded database for > tests. Can you please test it out again? > > Thanks, > > Aaron > > > > > ________________________________ > From: Aaron Anderson <aaronander...@acm.org> > To: dev@ode.apache.org > Sent: Mon, March 15, 2010 12:06:29 PM > Subject: Re: JPA DAO refactoring. > > Hi Jeff, > > Thanks for the feedback! > > 1. I will do a checkout and a clean build and install on a different > machine to make sure I don t have any maven modules cached on my dev > machine. The SQLNonTransientConnectionException class was added in JDK 1.6. > Since Sun EOL d 1.5 last fall so I assumed the trunk was dependent on 1.6. I > will make the needed changes to make sure 1.5 works as well. > > 2. That is strange. A top level mvn clean install worked for me and should > have caught this. Maybe it was a problem with my windows git client. I ll > fix this. > > 3. That makes sense. Il-common is a better place for it. > > 4. I haven t tried H2 yet, just Hsql and derby. I had a couple of problems > with hsql and blobs and sequences so I switched to derby. H2 might be a > better choice since it is lighter weight and has a more mature in memory > implementation. > > Sorry about the build problems, I will make sure the branch builds on > another machine besides my workstation. > > Cheers, > > Aaron > > On Mon Mar 15th, 2010 9:54 AM CDT Jeff Yu wrote: > > >Hi Aaron, > > > >When I checked out the latest code from trunk, I have following > >observations: > > > >1. When I run the 'mvn clean install', I've got following exception: (in > the > >bpel-dao) > > > > >/local/works/gitode/ode/bpel-dao/src/main/java/org/apache/ode/dao/DerbyJDBCContext.java:[8,16] > >cannot find symbol > >symbol : class SQLNonTransientConnectionException > >location: package java.sql > > > > >/local/works/gitode/ode/bpel-dao/src/main/java/org/apache/ode/dao/DerbyJDBCContext.java:[57,13] > >cannot find symbol > >symbol : class SQLNonTransientConnectionException > >location: class org.apache.ode.dao.DerbyJDBCContext > > > > >/local/works/gitode/ode/bpel-dao/src/main/java/org/apache/ode/dao/DerbyJDBCContext.java:[66,14] > >cannot find symbol > >symbol : constructor SQLException(java.lang.Exception) > >location: class java.sql.SQLException > > > >2. I've found the > >dao-jpa/src/main/java/org/apache/ode/dao/jpa/JPAConnection.java 's name is > >not as same as the class name. > > > >3. With regard to the DerbyJDBContext, I believe we use this class for our > >tests, can we move this class out of bpel-dao module, as in the bpel-dao > >module, it is db agnostic, what do you think? > > > >4. I have a concern that we are using the derby database as our defaut mem > >db, afaik, we are trying to move away derby to H2. ( > >https://issues.apache.org/jira/browse/ODE-666), any ideas that could we > use > >the H2 to make all tests passed? > > > >Also, I am curious on how do you run the tests, as I tried to do the 'mvn > >clean install' from top-level, it always throw errors.. any other ways for > >you to work around? ;) > > > >Regards > >Jeff > > > >On Mon, Mar 15, 2010 at 10:25 AM, Aaron Anderson <aaronander...@acm.org > >wrote: > > > >> Hi Jeff, > >> > >> I committed my changes to the JPA branch. Now all the unit tests are > >> passing and I believe I have the hibernate, Hibernate JPA, and OpenJPA > DAO > >> modules working properly. I selected OpenJPA as the default DAO > >> implementation and also updated all the unit tests to remove HSQL and > use an > >> in memory Derby DB. I moved the few tests that were in dao-test into > >> bpel-test and then added a couple of extra rounds of surefire tests to > >> re-run DAO tests against the hibernate DAO modules. Please take a look > and > >> let me know what you think. I will begin to introduce the DAO pattern > into > >> the scheduler module this week. I will add scheduler implementations to > the > >> three DAO modules and probably just refactor the existing JDBC code and > >> leave it in the module. > >> > >> Regards, > >> > >> Aaron > >> > >> > > > >-- > >Cheers, > >Jeff Yu > > > >---------------- > >blog: http://jeff.familyyu.net > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
