I'm not a email list moderator, and one isn't around right now. Did you try sending an email to "dev-unsubscr...@roller.apache.org" from the gmail account you subscribed from? It should work.
Glen On 07/31/2013 09:23 AM, Yufu Huang wrote: > 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
