Re: [hibernate-dev] Indexing IDs of IndexedEmbedded components
I am not sure @DocumentId is the right place to host it. Should it be rather on
the embedding entity to be able to customize in which scenario id is indexed?
In a way, includePath="city.id" is the indicator I am looking for.
On 16 févr. 2012, at 11:54, Sanne Grinovero wrote:
> This is related to HSEARCH-1049: it seems that the new includePaths
> feature is not accepting paths including the id of embedded objects,
> as in:
>
> @IndexedEmbedded(prefix="location.",includePaths={"city.id","city.city","country.id","city.region.id"})
> public Address getAddress() { return address; }
>
> As the "id" is a special field.
>
> On the other hand, I remember people on forums [1] asking how to
> *avoid* having to include the ids of embedded objects stored in the
> index; I agree that often that's not needed, in fact I wasn't even
> expecting it.
>
> This seems to have been introduced by HSEARCH-108 - but it's not
> possible to "turn it off".
>
> What about having
>
> @DocumentId( name = "id", includeEmbedded = true )
> @ProvidedId( name = "id", includeEmbedded = true )
> ?
>
> This would default to _true_ (also when no @DocumentId/Provided is
> explicitly defined).
>
> Getting back to the issue about
> @IndexedEmbedded(includePaths={"city.id"}), the validation should be
> accepted only when it's included in it's embedded form.
>
> [1] - sorry can't find the references - in addition to other users
> this affected myself as well in the past.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] API to clear/evict all caches in a session factory
Hi all, Re: http://java.dzone.com/tips/clearing-hibernate-second-leve Re: https://community.jboss.org/message/718710#718710 Shouldn't Hibernate offer an API (independent of the cache provider) to clear all 2LC caches, including all entity, all collection and all query/timestamp caches? Beneath it, each cache provider would implement this as it wishes to do so, but the knowledge of all caches within a session factory is in Hibernate core itself. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API to clear/evict all caches in a session factory
There is already: sf.getCache().evictEntityRegions() sf.getCache().evictCollectionRegions() sf.getCache().evictDefaultQueryRegion() sf.getCache().evictQueryRegions() I can see a benefit to having evictQueryRegions() imply evictDefaultQueryRegion() But, I fail to see a real benefit to a singular sf.getCache().oneEvictionToRuleThemAll() On Wed 22 Feb 2012 09:49:35 AM CST, Galder Zamarreño wrote: > Hi all, > > Re: http://java.dzone.com/tips/clearing-hibernate-second-leve > Re: https://community.jboss.org/message/718710#718710 > > Shouldn't Hibernate offer an API (independent of the cache provider) to clear > all 2LC caches, including all entity, all collection and all query/timestamp > caches? > > Beneath it, each cache provider would implement this as it wishes to do so, > but the knowledge of all caches within a session factory is in Hibernate core > itself. > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API to clear/evict all caches in a session factory
Well one reason would be to trigger clearing of the update-timestamps cache. I am leery of exposing a method to allow just that fuinctionality. On Wed 22 Feb 2012 10:00:43 AM CST, Steve Ebersole wrote: > There is already: > sf.getCache().evictEntityRegions() > sf.getCache().evictCollectionRegions() > sf.getCache().evictDefaultQueryRegion() > sf.getCache().evictQueryRegions() > > I can see a benefit to having evictQueryRegions() imply > evictDefaultQueryRegion() > > But, I fail to see a real benefit to a singular > sf.getCache().oneEvictionToRuleThemAll() > > On Wed 22 Feb 2012 09:49:35 AM CST, Galder Zamarreño wrote: >> Hi all, >> >> Re: http://java.dzone.com/tips/clearing-hibernate-second-leve >> Re: https://community.jboss.org/message/718710#718710 >> >> Shouldn't Hibernate offer an API (independent of the cache provider) >> to clear all 2LC caches, including all entity, all collection and all >> query/timestamp caches? >> >> Beneath it, each cache provider would implement this as it wishes to >> do so, but the knowledge of all caches within a session factory is in >> Hibernate core itself. >> >> Cheers, >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
