Could someone unsubscribe me from this mail list? I tried unsubscribe email but did not work. Thanks.
Sent from my iPhone On Jul 30, 2013, at 3:36 PM, 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/** >>>>>> ****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 >
