Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types
But then the JSON binding technology should be responsible for the property anme conversion too, right? After all that is the layer that does this change. On Thu 2013-09-19 10:35, Gunnar Morling wrote: > I also think that the conversion of the ConstraintViolation(s) into another > format is more in the responsibility of the integrating technology. > > Taking JAX-RS/Resteasy as example, it will transparently convert any > constraint violation objects into an equivalent XML or JSON response. > Provided we return the wished property name in the reported violation, > Resteasy's conversion would take over from there. > > > 2013/9/19 Hardy Ferentschik > > > > > On 19 Jan 2013, at 9:44 AM, Emmanuel Bernard > > wrote: > > > > > It seems that what this user really needs is a way to convert the > > Set into another format entirely, JSON in this case. I > > wonder if we could find a more generic approach than just the ability to > > change properties names. > > > > Well, there are really two problems. First the creation of the JSON format > > and then the property name "conversion". I think they need to be addressed > > separately. Even if we had/offered something to convert the constraint > > violations, we still > > would report the actual property name. > > > > In the described use case I would write the conversion code myself. The > > constraint violation contains all the information needed to create the JSON > > format and do the name conversion. It should not be hard to write. > > > > --Hardy > > > > > > ___ > > 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Hibernate OGM @ Devoxx
Nice :) On Mon 2013-09-09 15:38, Guillaume SCHEIBEL wrote: > Hello, > > After SoftShake (and few JUGs), I'm proud (and kind of exited) to announce > my Tool In Action titled "a hint of NoSQL into my Java EE" has been > approved. > > See you there :) > Guillaume > ___ > 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
Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types
On 2 Jan 2013, at 2:46 PM, Emmanuel Bernard wrote: > But then the JSON binding technology should be responsible for the > property anme conversion too, right? After all that is the layer that > does this change. That would be my initially gut feeling as well. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Should we deprecate @Similarity
Yes that was a mistake. It was done as you say to make things simpler for the user but it has created headaches for us since then. On Thu 2013-09-19 16:15, Sanne Grinovero wrote: > Discussing about some hibernate-search-engine complexities with Hardy > on IRC, we came to the agreement that the way @Similarity behaves > today was a mistake, so we're proposing to deprecate it in 4.4. > > Reasoning follows. > > There is a strong requirement in Lucene that all operations on the > same index need to use the same Similarity implementation. We infer > the org.apache.lucene.search.Similarity to be used on a specific index > from either: > > - the similarity property from the configuration file, which is > positioned on an index name > - the @Similarity annotation positioned on an indexed entity > > The trouble is about all these options needing to be consistent; first > problem is there isn't a precedence rule: if one of them is not > specified, we assume the user is using the other way to configure > things. But also different entities might be sharing the same index, > which leads to needing to verify that at least the user isn't > specifying some contradictory option. > > This all gets more confusing when you introduce the notion of > dynamically added new entities (a feature used by Infinispan) and/or > Dynamic Sharding, in which the properties of some indexes might > conflict with the specified @Similarity, but we might notice this only > at runtime rather than at bootstrap. Failing to load a class at this > point is far more annoying to the users than to fail the health-check > at bootstrap time. > > So the proposal: > drop the @Similarity annotation and use properties exclusively. > Properties are more suited for this as they are set on a per-index > base, which is what matters in this case. > > Downside: > I guess lots of people where using a single index per type, and for > those there was no danger to simply specify a @Similarity. We lose > this straight-forward way of things, but I'd argue that if you're in > the business of specifying a custom Similarity, you're a very advanced > user and wouldn't mind setting a one-liner in your configuration file. > > Do we agree? > > Sanne > ___ > 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
Re: [hibernate-dev] [Search] Dynamic Sharding the second
Turning the problem upside down, I wonder if IndexShardingStrategy should be deprecated and have SharIdentifierProvider as the API a user would implement. It makes for simpler things. What would we lose feature wise? Emmanuel On Fri 2013-09-20 17:30, Hardy Ferentschik wrote: > Hi, > > here comes a follow up on my previous email regarding configuration of > dynamic sharding. > > Now I would like to get some feedback on ShardIdentifierProvider. This > interface was added for dynamic sharding on > top of DynamicShardingStrategy. Gunnar and I had a discussion around it today > [1] and we came to the conclusion that > this interface is actually not needed and just adds confusion in the API. > > Really ShardIdentifierProvider is a IndexShardingStrategy in disguise. Add > 'forAddtion' and 'forDeletion' to the two 'getShardIdentifier' methods > and you have (almost) an IndexShardingStrategy. The problem seems to be, that > in order to implement dynamic sharding the > IndexManagerHolder and EntityIndexBinding are needed. > IndexShardingStrategy#initialize does not provide access to these objects > which maybe > led to the current design. > > In DynamicShardingStrategy this is taken care of by passing > IndexManagerHolder and EntityIndexBinding as part of the constructor > arguments. > Otherwise DynamicShardingStrategy is just a very thin wrapper delegating to > the ShardIdentifierProvider. > > If the current IndexShardingStrategy#initialize method would get passed the > required information for dynamic sharding, there would be no need > for an additional interface like ShardIdentifierProvider. Dynamic sharding > could be implemented with the existing extension points and implementations > would fit better into the current pattern of providing custom > implementations. > > What we could do is to make DynamicShardingStrategy an interface extending > IndexShardingStrategy and adding a second initialise contract > of sorts. This would keep backwards compatibility, but also allow for dynamic > sharding by users implementing DynamicShardingStrategy. > > At the downside the user would have to write a bit more code, but I think > that's acceptable given the more consistent approach towards sharding. > > Thoughts? > > --Hardy > > P.S. In case you guys think that we really should hold on to > ShardIdentifierProvider, I would at least suggest to either rename > the two 'getShardIdentifier' methods adding 'forAddition' and 'forDeletion' > or even collapse the two into a single method (not sure > whether this is easily possible) > > > [1] > http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2013/%23hibernate-dev.2013-09-20.log.html > ___ > 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
Re: [hibernate-dev] [OGM] Hibernate OGM @ Devoxx
Thanks, I'm scheduled on Monday at 6:05PM. Hope to see you (all) there :) Guillaume PS: if someone could dedicate ~1h within the month for a dry-run session, I would appreciate it. Guillaume 2013/10/2 Emmanuel Bernard > Nice :) > > On Mon 2013-09-09 15:38, Guillaume SCHEIBEL wrote: > > Hello, > > > > After SoftShake (and few JUGs), I'm proud (and kind of exited) to > announce > > my Tool In Action titled "a hint of NoSQL into my Java EE" has been > > approved. > > > > See you there :) > > Guillaume > > ___ > > 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
Re: [hibernate-dev] [Search] Dynamic Sharding the second
On 2 Jan 2013, at 3:06 PM, Emmanuel Bernard wrote: > Turning the problem upside down, I wonder if IndexShardingStrategy > should be deprecated and have SharIdentifierProvider as the API a user > would implement. It makes for simpler things. What would we lose feature > wise? That is exactly what we have done and we don't think anything is lost :-) --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Hibernate OGM @ Devoxx
Good idea. Plan a hangout and force Davide and Gunnar to be there. I'll try and join as well. Avoid Oct 14-16th, 22th-23rd and 28th -> Nov 1st Emmanuel On Wed 2013-10-02 15:14, Guillaume SCHEIBEL wrote: > Thanks, I'm scheduled on Monday at 6:05PM. > > Hope to see you (all) there :) > Guillaume > > PS: if someone could dedicate ~1h within the month for a dry-run session, I > would appreciate it. > > Guillaume > > > 2013/10/2 Emmanuel Bernard > > > Nice :) > > > > On Mon 2013-09-09 15:38, Guillaume SCHEIBEL wrote: > > > Hello, > > > > > > After SoftShake (and few JUGs), I'm proud (and kind of exited) to > > announce > > > my Tool In Action titled "a hint of NoSQL into my Java EE" has been > > > approved. > > > > > > See you there :) > > > Guillaume > > > ___ > > > 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
Re: [hibernate-dev] [Search] Dynamic Sharding the second
On Wed 2013-10-02 15:19, Hardy Ferentschik wrote: > > On 2 Jan 2013, at 3:06 PM, Emmanuel Bernard wrote: > > > Turning the problem upside down, I wonder if IndexShardingStrategy > > should be deprecated and have SharIdentifierProvider as the API a user > > would implement. It makes for simpler things. What would we lose feature > > wise? > > That is exactly what we have done and we don't think anything is lost :-) I should take more time offline then it seems. Fine by me ;) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Hibernate OGM @ Devoxx
Sounds like a good idea. Let me know when you have a date. By the way, congratulations for the event :) Cheers, Davide On Wed, Oct 2, 2013 at 3:15 PM, Emmanuel Bernard wrote: > Good idea. Plan a hangout and force Davide and Gunnar to be there. I'll > try and join as well. > Avoid Oct 14-16th, 22th-23rd and 28th -> Nov 1st > > Emmanuel > > On Wed 2013-10-02 15:14, Guillaume SCHEIBEL wrote: > > Thanks, I'm scheduled on Monday at 6:05PM. > > > > Hope to see you (all) there :) > > Guillaume > > > > PS: if someone could dedicate ~1h within the month for a dry-run > session, I > > would appreciate it. > > > > Guillaume > > > > > > 2013/10/2 Emmanuel Bernard > > > > > Nice :) > > > > > > On Mon 2013-09-09 15:38, Guillaume SCHEIBEL wrote: > > > > Hello, > > > > > > > > After SoftShake (and few JUGs), I'm proud (and kind of exited) to > > > announce > > > > my Tool In Action titled "a hint of NoSQL into my Java EE" has been > > > > approved. > > > > > > > > See you there :) > > > > Guillaume > > > > ___ > > > > 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Dynamic Sharding the second
Sorry if it looks like we had abandoned this thread: we continued the discussion in the first thread opened by Hardy. On 2 October 2013 15:16, Emmanuel Bernard wrote: > On Wed 2013-10-02 15:19, Hardy Ferentschik wrote: >> >> On 2 Jan 2013, at 3:06 PM, Emmanuel Bernard wrote: >> >> > Turning the problem upside down, I wonder if IndexShardingStrategy >> > should be deprecated and have SharIdentifierProvider as the API a user >> > would implement. It makes for simpler things. What would we lose feature >> > wise? >> >> That is exactly what we have done and we don't think anything is lost :-) > > I should take more time offline then it seems. Fine by me ;) > ___ > 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
Re: [hibernate-dev] [Search] Dynamic sharding configuration
On Tue 2013-09-24 10:51, Hardy Ferentschik wrote: > String[] getShardIdentifiers(Class entity, Serializable id, String > idInString); > > all together. Here is my reasoning. AFAIU, the method is there for the > deletion of > documents. In this case we don't have the Lucene document nor the entity and > we need > to know in which shard the document to delete is. The assumptions behind this > method is > that somehow given the type and id I am able to provide this shard or a > subset of the shards. > I doubt, however, that this is practically ever possible. In the end most > implementations will > have to just delegate to getAllShardIdentifiers() anyways. Take the language > code example or > any other case where I shard depending on a given property of the entity. In > this case I will > never be able to make any use of #getShardIdentifiers(Class , Serializable > , String) > > In fact the same arguments probably apply to getShardIdentifiersForQuery. > What is the use case > for that really? In which use case can the set of targeted shards be limited > based on knowing the > type of filers we apply? > > So why not remove #getShardIdentifiers and #getShardIdentifiersForQuery and > start of with a much > simpler interface. We can indeed mark it as experimental and if the need > arises (based on a true use case) > think about optimisations. > > The more I think about it, the more I like this more minimalistic approach. When ISStrategy was introduced the idea was that somehow, the implementor could receive information from the runtime with the right (set of) shard(s). For example, in a multi-tenant app and I *know* what shard the currently logged user is allowed to temper with. I will always filter by that shard even for deletion. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
