Glen, I have made some changes to enable local testing and after updating from the trunk nothing is working.
http://repo1.maven.org/ says 501. Why does it not ignore this? :( Can you see if the tests still work? Also, I have done the test on the directory and will check this later when its back working. Cheers Greg. On 30 July 2013 21:36, Glen Mazza <glen.ma...@gmail.com> wrote: > Fixed the Eclipselink issue in a way that the code will still work with > Hibernate. We'll keep the Hibernate for awhile to see if it has any issues. > > When we delete a media folder, Eclipselink does indeed remove it from the > database (the Flush Mode COMMIT/AUTO had nothing to do with the problem.) > The issue is that Eclipselink does not refresh the media folder's parent > to remove that deleted media folder from its child directories list. So > even though its removed from the database the application would still show > the deleted folder whenever you list a parent folder's (for us, "/") > children. For the change, I just manually removed the deleted folder from > its parent's subfolder list, which Hibernate is fine with. > > I may want to create a bare-bones example of this on StackOverflow > sometime and ask which JPA stack has it right, the losing stack gets a JIRA > issue. > > Glen > > > On 07/30/2013 07:06 AM, Greg Huber wrote: > >> Glen, >> >> OK, can you make the changes to the trunk so i can switch to hibernate. >> >> On 30 July 2013 11:47, Glen Mazza <glen.ma...@gmail.com> wrote: >> >> Much appreciated. I was thinking it may be good for us to run on >>> Hibernate for a few weeks anyway, even if EclipseLink were running >>> perfectly, just to see if there are any kinks with it where our code >>> needs >>> to be tightened up. I can fix EclipseLink's problem in the interim so >>> if/when *Hibernate* has a kink, we know we can always immediately flip >>> back >>> to EclipseLink while fixing the Hibernate issue. >>> >>> Glen >>> >>> On 07/30/2013 06:39 AM, Greg Huber wrote: >>> >>> Glen, >>>> >>>> I was trying to add the usecase but ran into the howto debug issue. I >>>> will >>>> sort the test if I manage to get the debug working. >>>> >>>> Cheers Greg >>>> >>>> On 30 July 2013 11:05, Glen Mazza <glen.ma...@gmail.com> wrote: >>>> >>>> Let me play with it today before throwing in the towel and going with >>>> >>>>> Hibernate. Even if we jump to Hibernate I still need to figure out the >>>>> EclipseLink matter so our coding is not dependent on one JPA framework >>>>> alone, we should be able to work with both or have a JIRA ticket with >>>>> EclipseLink. I'd like to add in a JUnit test case that would have >>>>> caught >>>>> this regression. >>>>> >>>>> Glen >>>>> >>>>> On 07/30/2013 03:31 AM, Greg Huber wrote: >>>>> >>>>> Glen, >>>>> >>>>>> Commenting out the FlushModeType.COMMIT makes no difference, (assumes >>>>>> it >>>>>> switches to auto). Would have thought that createNamedQuery or >>>>>> createQuery >>>>>> would behave the same way as they both follow the same logic in >>>>>> roller. >>>>>> Where one works and one does not, maybe an EclipseLink issue. I am no >>>>>> expert but with hibernate this does not happen. >>>>>> >>>>>> For me, eclipse does not have a good track record wrt QA, and with orm >>>>>> there is just no workaround. It would simpler if we can switch to >>>>>> something that works without all this pain. >>>>>> >>>>>> Cheers Greg >>>>>> >>>>>> >>>>>> On 29 July 2013 14:27, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>> >>>>>> This page: >>>>>> http://docs.oracle.com/javaee/****<http://docs.oracle.com/javaee/**> >>>>>> ****6/api/javax/persistence/****<http://docs.oracle.com/** >>>>>> javaee/****6/api/javax/**persistence/**<http://docs.oracle.com/javaee/****6/api/javax/persistence/**> >>>>>> > >>>>>> **<http://docs.oracle.com/****javaee/**6/api/javax/****persistence/**<http://docs.oracle.com/**javaee/**6/api/javax/**persistence/**> >>>>>> <http://docs.**oracle.com/javaee/**6/api/**javax/persistence/**<http://docs.oracle.com/javaee/**6/api/javax/persistence/**> >>>>>> > >>>>>> >>>>>>> FlushModeType.html<http://****do**cs.oracle.com/javaee/6/**api/**<http://cs.oracle.com/javaee/6/api/**> >>>>>>> <http://docs.oracle.com/**javaee/6/api/**<http://docs.oracle.com/javaee/6/api/**> >>>>>>> > >>>>>>> javax/persistence/******FlushModeType.html<http://** >>>>>>> docs.oracle.com/javaee/6/api/****javax/persistence/**** >>>>>>> FlushModeType.html<http://docs.oracle.com/javaee/6/api/**javax/persistence/**FlushModeType.html> >>>>>>> <http://**docs.oracle.com/javaee/6/api/**javax/persistence/** >>>>>>> FlushModeType.html<http://docs.oracle.com/javaee/6/api/javax/persistence/FlushModeType.html> >>>>>>> > >>>>>>> >>>>>>>> says >>>>>>>>> >>>>>>>> "If |FlushModeType.COMMIT| is set, the effect of updates made to >>>>>>> entities in the persistence context upon queries is unspecified", >>>>>>> which >>>>>>> is >>>>>>> different from the definition of COMMIT below (where it *only* occurs >>>>>>> at >>>>>>> a >>>>>>> transaction commit.) If I understand that correctly, that would mean >>>>>>> Roller can't rely on a flush having occurred or not with COMMIT, and >>>>>>> EclipseLink and any other JPA implementation is welcome to go either >>>>>>> way, >>>>>>> and can indeed behave differently between named and dynamic queries, >>>>>>> as >>>>>>> EclipseLink does. >>>>>>> >>>>>>> Might the problem be with our code? We're relying on unspecified >>>>>>> functionality when we set FlushModeType to COMMIT, and we've been >>>>>>> lucky >>>>>>> so >>>>>>> far that OpenJPA and Hibernate just so happen to flush data (as it's >>>>>>> allowed to do per the spec) while EclipseLink is choosing not to. I >>>>>>> wonder >>>>>>> if we should have new versions of NamedQuery and DynamicQuery that >>>>>>> *don't* >>>>>>> set it to COMMIT (assuming the default of AUTO is being used >>>>>>> otherwise, >>>>>>> as >>>>>>> specified here: http://www.eclipse.org/**** >>>>>>> eclipselink/documentation/2.5/********<http://www.eclipse.org/******<http://www.eclipse.org/****> >>>>>>> eclipselink/documentation/2.5/******<http://www.eclipse.org/**** >>>>>>> eclipselink/documentation/2.5/****<http://www.eclipse.org/**eclipselink/documentation/2.5/**> >>>>>>> > >>>>>>> jpa/extensions/p_persistence_********context_flushmode.htm)--******* >>>>>>> *something< >>>>>>> http://www.eclipse.**org/****eclipselink/documentation/** >>>>>>> 2.5/jpa/extensions/p_******persistence_context_flushmode.**** >>>>>>> **htm)--something<http://www.****eclipse.org/eclipselink/** >>>>>>> documentation/2.5/jpa/****extensions/p_persistence_** >>>>>>> context_flushmode.htm)--****something<http://www.eclipse.** >>>>>>> org/eclipselink/documentation/**2.5/jpa/extensions/p_** >>>>>>> persistence_context_flushmode.**htm)--something<http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/p_persistence_context_flushmode.htm)--something> >>>>>>> > >>>>>>> >>>>>>>> that >>>>>>>>> >>>>>>>> the Media File stuff could apparently use here. >>>>>>> >>>>>>> Glen >>>>>>> >>>>>>> >>>>>>> On 07/29/2013 08:32 AM, Greg Huber wrote: >>>>>>> >>>>>>> Glen, >>>>>>> >>>>>>> I think its only on the named queries as if I delete a weblog entry >>>>>>>> it >>>>>>>> updates correctly, and uses a dynamic query. >>>>>>>> >>>>>>>> EntityManager em = getEntityManager(false); >>>>>>>> Query q = em.createNamedQuery(queryName)********; >>>>>>>> // Never flush for queries. Roller code assumes this behavior >>>>>>>> q.setFlushMode(FlushModeType.********COMMIT); >>>>>>>> return q; >>>>>>>> >>>>>>>> EntityManager em = getEntityManager(false); >>>>>>>> Query q = em.createQuery(queryString); >>>>>>>> // Never flush for queries. Roller code assumes this behavior >>>>>>>> q.setFlushMode(FlushModeType.********COMMIT); >>>>>>>> >>>>>>>> >>>>>>>> Cheers Greg >>>>>>>> >>>>>>>> On 29 July 2013 13:14, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>>>> >>>>>>>> OK, we can switch to Hibernate for the time being, and it works >>>>>>>> fine >>>>>>>> >>>>>>>> there, it's as simple a matter as commenting-out the EclipseLink >>>>>>>> >>>>>>>>> dependency >>>>>>>>> and uncommenting the Hibernate one in the app/pom.xml and doing an >>>>>>>>> mvn >>>>>>>>> clean install to get a new WAR. Still, I'd like to fix this >>>>>>>>> EclipseLink >>>>>>>>> issue, maybe there's some simple setting causing it not to work. >>>>>>>>> Note >>>>>>>>> our >>>>>>>>> EclipseLink is JPA 2.1 vs. Hibernate's (and the OpenJPA's) 2.0, >>>>>>>>> that >>>>>>>>> might >>>>>>>>> be part of the story. >>>>>>>>> >>>>>>>>> Glen >>>>>>>>> >>>>>>>>> On 07/29/2013 07:34 AM, Greg Huber wrote: >>>>>>>>> >>>>>>>>> From google: >>>>>>>>> >>>>>>>>> "By default, the database flush mode is set to AUTO. This means >>>>>>>>> that >>>>>>>>> >>>>>>>>>> the >>>>>>>>>> Entity-Manager performs a flush operation automatically as needed. >>>>>>>>>> In >>>>>>>>>> general, this occurs at the end of a transaction for >>>>>>>>>> transaction-scoped >>>>>>>>>> EntityManagers and when the persistence context is closed for >>>>>>>>>> application-managed or extendedscope EntityManagers. In addition, >>>>>>>>>> if >>>>>>>>>> entities with pending changes are used in a query, the persistence >>>>>>>>>> provider >>>>>>>>>> will flush changes to the database before executing the query.If >>>>>>>>>> the >>>>>>>>>> flush >>>>>>>>>> mode is set to COMMIT, the persistence provider will only >>>>>>>>>> synchronize >>>>>>>>>> with >>>>>>>>>> the database when the transaction commits.However, you should be >>>>>>>>>> careful >>>>>>>>>> with this, as it will be your responsibility to synchronize entity >>>>>>>>>> state >>>>>>>>>> with the database before executing a query. If you don’t do this >>>>>>>>>> and >>>>>>>>>> an >>>>>>>>>> EntityManager<http://docs.********or**acle.com/javaee/6/api/**** >>>>>>>>>> ** <http://acle.com/javaee/6/api/****> >>>>>>>>>> javax/** >>>>>>>>>> <http://acle.com/javaee/6/api/****javax/**<http://acle.com/javaee/6/api/**javax/**> >>>>>>>>>> ><http://acle.com/ >>>>>>>>>> **javaee/6/api/javax/** >>>>>>>>>> <http://acle.com/javaee/6/api/**javax/**<http://acle.com/javaee/6/api/javax/**> >>>>>>>>>> >> >>>>>>>>>> <http://oracle.com/**javaee/6/****api/javax/**<http://oracle.com/**javaee/6/**api/javax/**> >>>>>>>>>> <http://oracle.**com/**javaee/6/api/javax/**<http://oracle.com/**javaee/6/api/javax/**> >>>>>>>>>> > >>>>>>>>>> <http://oracle.**com/javaee/6/**api/javax/**<http://oracle.** >>>>>>>>>> com/javaee/6/api/javax/**<http://oracle.com/javaee/6/api/javax/**> >>>>>>>>>> > >>>>>>>>>> persistence/EntityManager.********html<http://docs.oracle.com/** >>>>>>>>>> ** <http://docs.oracle.com/**> >>>>>>>>>> javaee/6/api/javax/********persistence/EntityManager.******html< >>>>>>>>>> http://docs.oracle.com/******javaee/6/api/javax/**<http://docs.oracle.com/****javaee/6/api/javax/**> >>>>>>>>>> <http://**docs.oracle.com/**javaee/6/**api/javax/**<http://docs.oracle.com/**javaee/6/api/javax/**> >>>>>>>>>> > >>>>>>>>>> persistence/EntityManager.****html<http://docs.oracle.com/** >>>>>>>>>> javaee/6/api/javax/****persistence/EntityManager.**html< >>>>>>>>>> http://docs.oracle.com/**javaee/6/api/javax/** >>>>>>>>>> persistence/EntityManager.html<http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html> >>>>>>>>>> **> >>>>>>>>>> **> >>>>>>>>>> **> >>>>>>>>>> **> >>>>>>>>>> **>query >>>>>>>>>> returns stale entities from the database, the application can wind >>>>>>>>>> up >>>>>>>>>> in an inconsistent state." >>>>>>>>>> >>>>>>>>>> Did try to change it to auto but made no difference. >>>>>>>>>> >>>>>>>>>> On 29 July 2013 12:25, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> OK, I'll check, but what happens if you go to the Roller >>>>>>>>>> maintenance >>>>>>>>>> tab >>>>>>>>>> >>>>>>>>>> and click on "Flush blog" (that will normally empty out the >>>>>>>>>> cache) -- >>>>>>>>>> >>>>>>>>>> problem solved then? >>>>>>>>>>> >>>>>>>>>>> Note I had to bring back your changes after the move to fewer >>>>>>>>>>> modules, >>>>>>>>>>> I >>>>>>>>>>> might have missed something. >>>>>>>>>>> >>>>>>>>>>> Glen >>>>>>>>>>> >>>>>>>>>>> On 07/29/2013 07:20 AM, Greg Huber wrote: >>>>>>>>>>> >>>>>>>>>>> Glen, >>>>>>>>>>> >>>>>>>>>>> Can you test whether you can delete a media file folder? ie >>>>>>>>>>> add >>>>>>>>>>> a >>>>>>>>>>> >>>>>>>>>>> folder >>>>>>>>>>>> and then try and delete it. For me it seems to delete it OK but >>>>>>>>>>>> when >>>>>>>>>>>> you >>>>>>>>>>>> refresh the media file folder view it is still there. If I then >>>>>>>>>>>> shut >>>>>>>>>>>> down >>>>>>>>>>>> tomcat and restart it is gone. It seems something to do with >>>>>>>>>>>> its >>>>>>>>>>>> cache? >>>>>>>>>>>> >>>>>>>>>>>> checking: >>>>>>>>>>>> >>>>>>>>>>>> public Query getNamedQuery(String queryName) >>>>>>>>>>>> .... >>>>>>>>>>>> q.setFlushMode(FlushModeType.************COMMIT); >>>>>>>>>>>> >>>>>>>>>>>> it sets the query to flush on commit, which should in theory >>>>>>>>>>>> flush >>>>>>>>>>>> the >>>>>>>>>>>> query cache when the transaction is committed. >>>>>>>>>>>> >>>>>>>>>>>> Is there some callback method we need to call to get it to >>>>>>>>>>>> flush? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers Greg >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >
