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/** >>>> ****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://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/**** >>>>> 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> >>>>> >>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/**** >>>>>>>> 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/**> >>>>>>>> > >>>>>>>> persistence/EntityManager.******html<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/**> >>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >
