Re: [hibernate-dev] Hibernate Search: Adding more "hidden" fields to the index
by Yoann Rodiere
I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
field so that we can just use AddLuceneWorks everywhere, and run targeted
delete operations when we start a partition? If so, is it as a fallback
solution, if what I proposed cannot be implemented, or as a better
alternative? Note I don't have strong arguments against that solution, I'm
just trying to understand the "why".
On adding a hidden field, I wonder what this will mean for Elasticsearch;
if we start doing such things, we should clearly and explicitly state in
the documentation that targeting existing ES schemas without adapting them
to Hibernate Search is not supported.
On top of that, it may hurt users upgrading Hibernate Search: Lucene may
simply ignore queries against a field that doesn't exist in the index, but
I'm not sure Elasticsearch behaves that way when the field isn't even
defined in the mapping. So users may have to upgrade their schema just for
that. I know Elasticsearch integration is experimental anyway, but what I
mean is if we do that, it must be *before* Elasticsearch we drop the
"experimental" mention on Elasticsearch integration.
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
On 27 April 2017 at 15:59, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
> field so that we can just use AddLuceneWorks everywhere, and run targeted
> delete operations when we start a partition? If so, is it as a fallback
> solution, if what I proposed cannot be implemented, or as a better
> alternative? Note I don't have strong arguments against that solution, I'm
> just trying to understand the "why".
>
> On adding a hidden field, I wonder what this will mean for Elasticsearch;
> if we start doing such things, we should clearly and explicitly state in
> the documentation that targeting existing ES schemas without adapting them
> to Hibernate Search is not supported.
> On top of that, it may hurt users upgrading Hibernate Search: Lucene may
> simply ignore queries against a field that doesn't exist in the index, but
> I'm not sure Elasticsearch behaves that way when the field isn't even
> defined in the mapping. So users may have to upgrade their schema just for
> that. I know Elasticsearch integration is experimental anyway, but what I
> mean is if we do that, it must be *before* Elasticsearch we drop the
> "experimental" mention on Elasticsearch integration.
>
>
> Yoann Rodière
> Software Engineer, Hibernate NoORM Team
> Red Hat
> yrodiere(a)redhat.com
>
> On 27 April 2017 at 15:23, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
>> To better implement recovery operations during MassIndexer
>> [HSEARCH-2616] - specifically in the context of the upcoming JBatch
>> based implementation - I'm considering the benefits of adding one more
>> field the the Lucene index for our internal purposes.
>>
>> This new field is only useful for Hibernate Search internals so we
>> shouldn't allow it to be targeted by queries, etc..
>>
>> There is a single precedent: we already encode the entity name, so
>> "hiding fields" is not a new problem that we have to deal with. It
>> might be a reason to polish the existing concept and improve the
>> encapsulation.
>>
>> Would anyone have a strong case against this?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
9 years
OGM - Let's remove Fongo support
by Guillaume Smet
Hi,
So, in OGM, for MongoDB, we also support running the tests with Fongo which
is an in-memory Java (more or less accurate) MongoDB implementation.
It has a cost as Fongo behaves differently and we have to disable
tests/implement different tests without any real benefits IMHO:
- it's easy to run MongoDB embedded for testing: this is what we use by
default
- we leave in a Docker world so people might also spawn a containerized
MongoDB instance for testing
When moving to the new MongoDB API, we have a couple more
differences/things not working with Fongo and I really don't see the point
of maintaining this. It adds an unnecessary burden to changes made to the
MongoDB datastore.
If no one speaks against it, I'll remove it soon.
--
Guillaume
9 years
Hibernate Search: Adding more "hidden" fields to the index
by Sanne Grinovero
To better implement recovery operations during MassIndexer
[HSEARCH-2616] - specifically in the context of the upcoming JBatch
based implementation - I'm considering the benefits of adding one more
field the the Lucene index for our internal purposes.
This new field is only useful for Hibernate Search internals so we
shouldn't allow it to be targeted by queries, etc..
There is a single precedent: we already encode the entity name, so
"hiding fields" is not a new problem that we have to deal with. It
might be a reason to polish the existing concept and improve the
encapsulation.
Would anyone have a strong case against this?
Thanks,
Sanne
9 years
Hibernate development in Eclipse IDE?
by Arnold Gálovics
Hi all,
Does anyone have issues with the hibernate-core module in Eclipse?
*I'm getting the following errors there:*
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type AbstractBulkCompositeIdTest
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type AbstractBulkIdTest
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type AbstractSkipLockedTest
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type AbstractSkipLockedTest
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type AbstractSkipLockedTest
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type BatchOptimisticLockingTest BatchOptimisticLockingTest.java
The method doInHibernate(Supplier<SessionFactory>,
TransactionUtil.HibernateTransactionFunction<Object>) is ambiguous for the
type InformixFunctionTest
Type mismatch: cannot convert from NativeQuery to NativeQueryImplementor
SessionDelegatorBaseImpl.java
I also had some cyclic dependency issues within the modules but that can be
solved by disabling the error in Eclipse. These issues are not present in
IntelliJ anyhow.
Does anyone experience the same? Shouldn't this be fixed or the official
IDE for Hibernate is IntelliJ?
Thanks!
Best Regards,
Arnold
9 years
GitHub security: key validation required
by Sanne Grinovero
Hi all,
we updated some options on the Hibernate organization on Github which
will require you to validate any existing keys you might be using on
GitHub.
For example when you try to push commits you might see an error, but
this error should contain a reasonable explanation and a link to a
page, were you'll find a nice and simple UI inviting you to explicitly
validate your keys.
It only takes a minute, sorry for the inconvenience.
Thanks,
Sanne
9 years
Maven 3.2.5 on CI
by Davide D'Alto
Hi,
We still have an old version of Maven installed on CI, is there
anybody using it?
Otherwise I would prefer to remove it.
Thanks,
Davide
9 years
[feature request][discuss] smoother serializers integration?
by Romain Manni-Bucau
Well here is how I see things:
1. mappers: until model is different from the jpa mapping it doesn't make
much sense and with microservices and failfast trends it doesn't make as
much sense as it was some years ago - plese don't assume I agree but just
sharing what I see.
1.bis. you get the same issue with mappers if you think about it but just
add a layer after hibernate to reject that responsability. Worse case you
give it to the end user which prevents can prevent libraries/tooling
2. Mapping is already a DTO and to not create 10 DTO models per domain
entity you will likely get the same issue there. You can move back the
responsability to the mapper but once again same issue.
3. The nice thing with this GraphVisitor proposal (name is likely very bad)
is you can just bypass not initialized instances, something like:
return (HibernateProxy.class.isInstance(value) &&
HibernateProxy.class.cast(value).getHibernateLazyInitializer().isUninitialized())
||
PersistentCollection.class.isInstance(value) &&
!PersistentCollection.class.cast(value).wasInitialized();
4. I also get a hard time to figure out why defaulting in case of a
detached entity is bad. Take the getSingleResult() example: spec throws an
exception if no result if found but most of usages are to wrap it to return
null instead cause it makes the code more fluent.
Also not sure how it can be different from data access best practise. Here
a usage i'm thinking about - the one I hit currently -:
// -start tx
Collection<MyEntity> entities = em.createNamedQuery("query with
fetch")....getResultList();
// here I loaded all the graph I need, what is still lazy doesnt need to be
loaded at all
// -end tx
// here the collection should just be as any DTO since it is no more in JPA
land
Now assume you use a DTO - which is the proposal, code will be:
Collection<MyEntity> entities = fetchEntities();
Collection<MyDto> dtos = map(entities);
// here is MyDto has the representation of a relationship it will not lazy
load it but can still be called
What does it mean? There is still a gap in the JPA usage of entities with
hibernate and normal java code (openjpa for instance doesnt have that issue
since when the entity is detached it return what it has and doesnt try to
use any connection).
>From my point of view it affects the serializer case, of course, but also
the resource management (lazy connections are really really vicious and
rarely controlled). So at least a mode where the fetched value becomes kind
of no more aware of JPA would be great.
Hey Romain,
>
> I don't think it is a good idea to expose entities directly if you
> really need a subset of the data.
> Reasons for that thinking are that it gets hard to define what needs to
> be fetched or is safe to be used for a particular use case. Obviously
> serialization is like a follow-up problem.
> I see 2 possible solutions to the problem and both boil down to the use
> of DTOs.
>
> 1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
> custom DTO types.
> 2. Use specialized DTOs in queries.
>
>
> Implementing 1. does not help you with lazy loading issues and 2. might
> require very intrusive changes in queries which is why I implemented
> Blaze-Persistence Entity Views
> <https://github.com/beikov/blaze-persistence#entity-view-usage>.
> This is a library that allows you to define DTOs with mappings to the
> entity. In a query you can define that you want results to be
> "materialized" as instances of the DTO type.
> This reduces the pain induced by properly separating the "presentation
> model" from the "persistence model" and at the same time will improve
> the performance by utilizing the mapping information.
> I don't want to advertise too much, just wanted to say that I had the
> same issues over and over which is why I started that project.
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> > Hi guys,
> >
> > Short sumarry: Wonder if hibernate could get a feature to kind of either
> > unproxy or freeze the entities once leaving the managed context to avoid
> > uncontrolled lazy loading on one side and serialization issues on another
> > side.
> >
> > Use case example: a common example is a REST service exposing directly
> > hibernate entities (which is more and more common with microservice
> > "movement").
> >
> > Objective: the goal is to not need any step - or reduce them a lot -
> > between the hibernate interaction and a potential serialization to avoid
> > issues with lazy loading and unexpected loading. Today it requires some
> > custom and hibernate specific logic in the serializer which kind of
> breaks
> > the transversality of the two concerns (serialization and object
> > management/loading).
> >
> >
> > Implementation options I see:
> >
> > 1. a callback requesting if the lazy relationship should be fetched,
> > something like
> >
> > public interface GraphVisitor {
> > boolean shouldLoad(Object rootEntity, Property property);
> > }
> >
> > 2. An utility to remove any proxy potentially throwing an exception and
> > replacing the value by null or an empty collection, something like
> >
> > MyEntity e = Hibernate.deepUnproxy(entity);
> >
> > 3. A switch of the proxy implementation, this is close to 2 but wouldn't
> > require a call to any utility, just a configuration in the persistence
> unit.
> >
> > Side note: of course all 3 options can be mixed to create a single
> solution
> > like having 3 implemented based on 1 for instance.
> >
> > Configuration proposal: this would be activated through a property in the
> > persistence unit (this shouldn't be only global IMHO cause otherwise you
> > can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
> > concrete). This should also be activable as a query hint i think - but
> more
> > a nice to have.
> >
> >
> > What this feature wouldn't be responsible for: cycles. If relationships
> are
> > bidirectional then the unproxied entity would still "loop" if you browse
> > the object graph - this responsability would stay in the consumer since
> it
> > doesn't depend on hibernate directly but more on a plain object handling.
> >
> > What do you think?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 19 Apr 2017 14:29:40 +0300
> From: Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
> Subject: Re: [hibernate-dev] [feature request][discuss] smoother
> serializers integration?
> To: Christian Beikov <christian.beikov(a)gmail.com>
> Cc: hibernate-dev <hibernate-dev(a)lists.jboss.org>
> Message-ID:
> <CA+gWKMAzp2BhT+An=rRHtH7z5f9rjZE54eUb0y5y+7bSX5LPuw@mail.
> gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Although I keep on seeing this request from time to time, I still think
> it's more like a Code Smell.
> Entities are useful for when you plan to modify them. Otherwise, a DTO
> projection is much more efficient, and you don't suffer from
> LazyInitializationException.
>
> With the ResultTransformer, you can even build graphs of entities, as
> explained in this article;
>
> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-
> hibernate-resulttransformer-to-customize-result-set-mappings/
>
> Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
> it's difficult to replace a Proxy with null after the Session is closed. If
> we implemented this, we'd have to take into consideration both Javassist
> and ByteBuddy as well as ByteCode Enhancements.
>
> all in all, the implementation effort might not justify the benefit, and
> I'm skeptical of offering a feature that does not encourage data access
> Best Practices.
>
> Vlad
>
> On Wed, Apr 19, 2017 at 2:18 PM, Christian Beikov <
> christian.beikov(a)gmail.com> wrote:
>
> > Hey Romain,
> >
> > I don't think it is a good idea to expose entities directly if you
> > really need a subset of the data.
> > Reasons for that thinking are that it gets hard to define what needs to
> > be fetched or is safe to be used for a particular use case. Obviously
> > serialization is like a follow-up problem.
> > I see 2 possible solutions to the problem and both boil down to the use
> > of DTOs.
> >
> > 1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
> > custom DTO types.
> > 2. Use specialized DTOs in queries.
> >
> >
> > Implementing 1. does not help you with lazy loading issues and 2. might
> > require very intrusive changes in queries which is why I implemented
> > Blaze-Persistence Entity Views
> > <https://github.com/beikov/blaze-persistence#entity-view-usage>.
> > This is a library that allows you to define DTOs with mappings to the
> > entity. In a query you can define that you want results to be
> > "materialized" as instances of the DTO type.
> > This reduces the pain induced by properly separating the "presentation
> > model" from the "persistence model" and at the same time will improve
> > the performance by utilizing the mapping information.
> > I don't want to advertise too much, just wanted to say that I had the
> > same issues over and over which is why I started that project.
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> > > Hi guys,
> > >
> > > Short sumarry: Wonder if hibernate could get a feature to kind of
> either
> > > unproxy or freeze the entities once leaving the managed context to
> avoid
> > > uncontrolled lazy loading on one side and serialization issues on
> another
> > > side.
> > >
> > > Use case example: a common example is a REST service exposing directly
> > > hibernate entities (which is more and more common with microservice
> > > "movement").
> > >
> > > Objective: the goal is to not need any step - or reduce them a lot -
> > > between the hibernate interaction and a potential serialization to
> avoid
> > > issues with lazy loading and unexpected loading. Today it requires some
> > > custom and hibernate specific logic in the serializer which kind of
> > breaks
> > > the transversality of the two concerns (serialization and object
> > > management/loading).
> > >
> > >
> > > Implementation options I see:
> > >
> > > 1. a callback requesting if the lazy relationship should be fetched,
> > > something like
> > >
> > > public interface GraphVisitor {
> > > boolean shouldLoad(Object rootEntity, Property property);
> > > }
> > >
> > > 2. An utility to remove any proxy potentially throwing an exception and
> > > replacing the value by null or an empty collection, something like
> > >
> > > MyEntity e = Hibernate.deepUnproxy(entity);
> > >
> > > 3. A switch of the proxy implementation, this is close to 2 but
> wouldn't
> > > require a call to any utility, just a configuration in the persistence
> > unit.
> > >
> > > Side note: of course all 3 options can be mixed to create a single
> > solution
> > > like having 3 implemented based on 1 for instance.
> > >
> > > Configuration proposal: this would be activated through a property in
> the
> > > persistence unit (this shouldn't be only global IMHO cause otherwise
> you
> > > can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
> > > concrete). This should also be activable as a query hint i think - but
> > more
> > > a nice to have.
> > >
> > >
> > > What this feature wouldn't be responsible for: cycles. If relationships
> > are
> > > bidirectional then the unproxied entity would still "loop" if you
> browse
> > > the object graph - this responsability would stay in the consumer since
> > it
> > > doesn't depend on hibernate directly but more on a plain object
> handling.
> > >
> > > What do you think?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
> ------------------------------
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> End of hibernate-dev Digest, Vol 130, Issue 4
> *********************************************
>
9 years
CI Updates on the 20th of April
by Davide D'Alto
I will run some updates on Jenkins next Thursday (20th of April).
This should remove the red Warning one sees when logged in.
Problem is that some plugins changed the way they store configuration
and it might affects some jobs.
Thanks,
Davide
9 years
