Re: [hibernate-dev] [Search] Dynamic sharding configuration
What does Iterable give you over String[]? On Mon 2013-09-23 23:04, Sanne Grinovero wrote: > Correct me if I'm wrong, but trying to synthesize this discussion I > think that we're fundamentally agreeing that dynamic sharding is a > "better replacement" for static sharding. > Still, let's keep in mind that this needs to be a backwards compatible > patch, so we're not looking for something disruptive of the current > static sharding feature. If we end up agreeing that the better API > needs disruption, we should still make an incremental change available > in this version - as experimental - so that people can play with it, > then we're free to reset the API as we wish in 5.0 but at least > including the newly acquired experience. > > We then had some brainstorming on IRC which concluded that it would be > probably more user friendly to have the __Strategy to: > a) not return arrays but simple collections > b) avoid the confusion on the two too similar methods on the proposal > for ShardIdentifierProvider (next paragraph) > c) not apply the sharding logic based on the Document (fields) but on > the entity (the user type triggering the index event) > > As a reminder, the proposal for ShardIdentifierProvider is - omitting > initialize - : > > /** > * Returns the shard identifier upon addition. > */ > String getShardIdentifier(Class entity, Serializable id, String > idInString, Document document); > > /** > * Returns the set of shard identifiers upon deletion. > */ > String[] getShardIdentifiers(Class entity, Serializable id, > String idInString); > > /** > * Returns the set of shard identifiers for a query. > */ > String[] getShardIdentifiersForQuery(FullTextFilterImplementor[] > fullTextFilters); > > /** > * Returns the list of all known shard identifiers. > * The list can vary between calls. > */ > String[] getAllShardIdentifiers(); > > #a > Ok we can consider that but let's see how the code turns out. > Iterable perhaps? > > #b > we explored converging the two methods into the essential one: > >String getShardIdentifier(Class entity, Serializable id, String > idInString); > > but that seems very poor in terms of flexibility, it doesn't even > allow access to the basic properties of the indexed entity. So that > degenerated in the proposal #c, but before moving to #c I'd venture > that these methods aren't that bad, they just need good documentation. > Also, even if we move the focus from the Document to the Entity, we > still don't have the fully loaded entity during a delete operation, so > we would still need the second method returning multiple indexes. > > #c > drawbacks first: > = to expose the entity directly has probably some risk (the user > making changes to it), but that's no different to what the user can > already do from a FieldBridge / ClassBridge. > = won't be able to consider the output of FieldBridge / ClassBridge > instances as you won't have the Document > = for deletion you still don't have the entity > > We could list some conceptually interesting advantages here, but I'd > like to shut down this feature for the time being because it's > significantly different than the goal of providing Dynamic Sharding as > a feature. I'm not saying that it doesn't have merit: its probably > worth exploring for 5+ but it rather seems like an _additional_ level > of sharding that we might want to add in future as an alternative to > the one focusing on the Document approach. > > So assuming that sounds reasonable, and that we're on the same page > for a#, let's focus on b#: the duality of the methods for add/remove > during sharding. > My position is that it worked well so far on static sharding, and that > the proposal is quite consistent with it so wouldn't be much of a pain > for people to adapt the new model. Let's try polishing the method > names (and use your imagination for a well written javadoc): > > String getShardIdFromDocument(Class entity, Serializable id, > String idInString, Document document); > > Iterable getShardIdsFromId(Class entity, Serializable > id, String idInString); > > or maybe to highlight what's fundamentally different: > > String getShardIdFromContext(Class entity, Serializable id, > String idInString, Document document); > > Iterable getShardIdsFromReducedContext(Class entity, > Serializable id, String idInString); > > > I especially like the javadoc! well done. > WFYT? > > > Bonus dilemma: should we stay away from String and define some > "IndexIdentifier" interface ? Note that while design wise it might > look good, this is on a very hot path so while I'd like proposing such > an SPI it would be great if we could find a way in which this would > not require to allocate objects at runtime just to replace a mere > string with a safer type. > > Sanne > > > > On 23 September 2013 13:58, Hardy Ferentschik wrote: > > > > On 23 Jan 2013, at 1:55 PM
Re: [hibernate-dev] [Search] Dynamic sharding configuration
On Tue 2013-09-24 14:30, Sanne Grinovero wrote: > On 24 September 2013 14:12, Hardy Ferentschik wrote: > > 2) remove 'String[] getShardIdentifiers(Class entity, Serializable id, > > String idInString)' from ShardIdentifierProvider > > +1 we're automatically assuming a deletion needs to be routed to all > identifiers. Bad idea as I explained in my previous email. Plus we could already make use of that if we reuse Hibernate ORM's tenantid value. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Nice posts on Hibernate Search
You should blog and tweet them. On Tue 2013-10-01 11:51, Sanne Grinovero wrote: > Found this nice blog post: > > http://timontech.net/2013/08/27/adding-the-power-of-search-to-your-hibernate-app-the-easy-way/ > > He makes a good point on when it's useful to use. > > there also is a nice follow-up in form of a dzone quickstart: > https://twitter.com/DZone/status/384374190066765827 > > 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] checkNullability when deleting an entity
On Mon 2013-09-23 17:07, Steve Ebersole wrote: > Anyone have compelling reasons to continue to call > org.hibernate.engine.internal.Nullability#checkNullability when deleting > an entity? An entity being deleted can be validated by Bean Validation. But from what I understand you would not call checkNullability and thus leave room for BV to be called. Correct? > To a lesser degree, how about reasons for calling > org.hibernate.engine.internal.ForeignKeys.Nullifier#nullifyTransientReferences > > when deleting? > ___ > 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] Nice posts on Hibernate Search
On 2 October 2013 14:46, Emmanuel Bernard wrote: > You should blog and tweet them. You should follow this guy : https://twitter.com/hibernate :) BTW I just received this email some minutes ago, but it says "sent 22 hours ago" Sanne > > On Tue 2013-10-01 11:51, Sanne Grinovero wrote: >> Found this nice blog post: >> >> http://timontech.net/2013/08/27/adding-the-power-of-search-to-your-hibernate-app-the-easy-way/ >> >> He makes a good point on when it's useful to use. >> >> there also is a nice follow-up in form of a dzone quickstart: >> https://twitter.com/DZone/status/384374190066765827 >> >> 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] checkNullability when deleting an entity
With HV or BV enabled, generally speaking Nullability#checkNullability no-ops anyway.. On 10/02/2013 08:36 AM, Emmanuel Bernard wrote: > On Mon 2013-09-23 17:07, Steve Ebersole wrote: >> Anyone have compelling reasons to continue to call >> org.hibernate.engine.internal.Nullability#checkNullability when deleting >> an entity? > An entity being deleted can be validated by Bean Validation. But from > what I understand you would not call checkNullability and thus leave > room for BV to be called. Correct? > >> To a lesser degree, how about reasons for calling >> org.hibernate.engine.internal.ForeignKeys.Nullifier#nullifyTransientReferences >> when deleting? >> ___ >> 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] Nice posts on Hibernate Search
> BTW I just received this email some minutes ago, but it says "sent 22 hours > ago" Pretty good for i18l delivery. Fedex can be faster but not all the time. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] portions of JIRA down
FYI, portions of Hibernate JIRA are currently down. Any ticket that was in an "Awaiting Test Case" state will not work. We're working with Atlassian support to resolve it and will hopefully be back up shortly. Brett Meyer Software Engineer Red Hat, Hibernate ORM ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] portions of JIRA down
Correction -- nearly *all* of Hibernate JIRA tickets are now down :( Brett Meyer Software Engineer Red Hat, Hibernate ORM - Original Message - From: "Brett Meyer" To: "hibernate-dev" Sent: Thursday, October 3, 2013 12:55:40 PM Subject: [hibernate-dev] portions of JIRA down FYI, portions of Hibernate JIRA are currently down. Any ticket that was in an "Awaiting Test Case" state will not work. We're working with Atlassian support to resolve it and will hopefully be back up shortly. Brett Meyer Software Engineer Red Hat, Hibernate ORM ___ 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] IRC Developer Meeting - Oct 3
Various topics discussed today. Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-10-03-14.57.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-10-03-14.57.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-10-03-14.57.log.html ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] portions of JIRA down
JIRA is back up -- thank you for your patience! Brett Meyer Software Engineer Red Hat, Hibernate ORM - Original Message - From: "Brett Meyer" To: "hibernate-dev" Sent: Thursday, October 3, 2013 1:07:00 PM Subject: Re: [hibernate-dev] portions of JIRA down Correction -- nearly *all* of Hibernate JIRA tickets are now down :( Brett Meyer Software Engineer Red Hat, Hibernate ORM - Original Message - From: "Brett Meyer" To: "hibernate-dev" Sent: Thursday, October 3, 2013 12:55:40 PM Subject: [hibernate-dev] portions of JIRA down FYI, portions of Hibernate JIRA are currently down. Any ticket that was in an "Awaiting Test Case" state will not work. We're working with Atlassian support to resolve it and will hopefully be back up shortly. Brett Meyer Software Engineer Red Hat, Hibernate ORM ___ 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
