Re: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next steps
On 2 Jan 2014, at 23:20, Emmanuel Bernard wrote: > Hardy, I am starting to come along your side on this discussion. They key > things that made me swing is that if a user needs a special annotation to > customize the bridge, then it’s equivalent to a @FieldBridge. Exactly. And parameters you get in via @Parameter if you wan to > I am still a bit sceptical to move the bridge discovery to AMP - at least > when explicit annotations are at play because: > - AMP is complex It is still very complex for sure. I would love to spend more time on this. Basically it is just an extraction of the annotation processing from the DocumentBuilder with the difference that is uses now the builder pattern. The basic flow is the same though. Complex or not, processing of the annotation belong there, either directly or in another helper called from there. If you feel for it you can try to break up the whole class ;-) > - BridgeFactory seems a nice focal point to everything bridge related Right, all bridge related. That does imo not include dealing with annotations. We we said, o the BridgeFactory we could have things like buildSpatialBridge(…) which takes everything it needs to build such a bridge. However, the extraction of these parameter should happen as part of AnnotationMetadataProvider. > - a few common rules must be applied to bridges (like the IterableBridges / > MapBridges and ArrayBridges wrappers) Maybe. I dig not deep enough to see all the required detail, but it should be solvable. > Nevertheless the idea of inferring types via @FieldBridge, @TikeBridge, > @DateBridge, @Spatial in a separate method than guessType has merits. thanks > BUT > > In practice for Date related add-ons like JodaTime and Java 8 date, I am > wondering if we should ensure that someone can use @DateBridge. After all a > resolution is likely conceptually needed and forcing another annotation seems > wrong. This one is a border case. I could either handle this case specifically (not using the BridgeProvider) or we live with this shortcoming. It seems like a small flexibility loss and we would gain clearer design and API ;-) > Likewise for "Hibernate Spatial” types, it will probably make sense to > support them as annotated with @Spatial like we do for Coordinates. I have a hard time that anyone wants to literally override the brig for @Spatial. Once you want to customise there, you might as well not use @Spatial and do your own stuff. Same for @TikaBridge. To a certain degree they are just shorthands for @FieldBridge(impl=SpatialFoo.class). > - is that supposed to be supported by some other features unrelated to > BridgeProvider? Maybe. One idea could be to add a bridgeImpl attribute to @Spatial and @TikaBridge. But as said, see these two annotations more as already selecting one specific bridge type > - should we design BridgeProvider in a way that let them react to these built > in annotations? (via explicit methods I suppose). Not for me. At least not for the first cut. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
Hi, I think we dropped the ball on this one. I basically had a look at Guillaume’s pull request. His analysis was correct and his proposed patch brings back the old pre 4.4 behaviour with minimal changes. There is still the question of the indented use cases of @ContainedIn. As discussed in this thread afaik the indent was as a sole counterpart to @IndexedEmbedded. The implementation (probably as a side effect) made it also work when @IndexedEmbedded was not used. This was changed with the metamodel refactoring where contained in was indeed treated as counterpart of indexed embedded. I think we should go ahead and apply Guillaume’s pull request for 4.4 and 4.5, basically reinstating old 4.x behaviour, side effect or not. The next question is then what to do in Search 5. I think we can just carry forward the change/patch. I don’t think that @ContainedIn needs another attribute or that we should introduce a whole new annotation. @ContainedIn seems quite natural provided we documented it intend and behaviour. Basically all what @ContainedIn is saying, is that here we have a reference to another entity which needs reindexing as well when the current entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or via a custom bridge is irrelevant. Thoughts? —Hardy P.S. Sanne, are you planning 4.4 and 4.5 releases as well? Just asking due to the recent back ports. If so, we should include this patch as well. On 28 Jan 2014, at 14:32, Guillaume Smet wrote: > Hi again, > > I posted a pull request for the 4.5 branch: > https://github.com/hibernate/hibernate-search/pull/590 . Comments > welcome! > > I included a rather large test case I have extracted from our app. > It's simplified but I think you should get the idea by looking at it. > > All tests passes. > > FWIW, I find the new way to do it more consistent with the names of > the methods as updateContainedInMaxDepths now does exactly what its > name says. > > It would be nice if it could also be backported to 4.4.x. > > Glad to discuss further enhancements if needed but I think the old > behavior should be brought back before considering any further > enhancements/features. > > -- > Guillaume > > On Fri, Mar 28, 2014 at 1:28 PM, Guillaume Smet > wrote: >> Hi Sanne, >> >> On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero >> wrote: >>> However - I might not have fully grasped this yet - but I'm thinking >>> that this is a feature request and not a bugfix that should be hastily >>> applied on 4.4. >> >> It's not a feature request. 4.4 changed this behavior. It was working >> well with 4.3 (and every other versions before that). >> >>> Guillaume, I suspect you might be a happier user if you would keep >>> using a more bleeding edge version, so to catch any such thing earlier >>> rather than the day before you go in production. I can only promise >>> you that the migration to 5.0 will be a nightmare if you don't follow >>> along in small iterations :-( >> >> I don't think we can be more bleeding edge than us. We upgrade our >> core framework to new versions as soon as they are released (we coded >> https://www.artifact-listener.org/ for this purpose). That's why we >> spend a considerable amount of time doing QA on the components we use >> - you see a part of this work on ORM + Search but we also do it for >> other components. You might have noticed that we are often the first >> company out there to catch regressions. >> >> When we have the ability to dedicate cycles to it, we also test CR. >> >> But... we develop a lot of applications for a lot of customers and >> they have different lifecycles: we can upgrade some easily and for >> others we have to wait for the right opportunity to do it. >> >> All in all, we have the following policy: >> - all the applications in development: they use the latest versions of >> each components, except if we catch a regression when upgrading. If so >> we try to help fix it for the next version and we upgrade ASAP; >> - the applications in production are updated regularly for minor >> changes; If the changes are big, we wait for our customers to ask >> changes on the app and we do it then. >> >> The fact is that we caught this one while upgrading an app which was >> using 4.3.0.Final (which is not that old) but I think we have other >> applications already upgraded to 4.4.2 which have that bug, it's just >> that we haven't caught it when we upgraded. >> >> FWIW, we couldn't upgrade to 4.4.x before 4.4.2.Final because of a few >> regressions we reported and helped getting fixed (I have at least >> these ones in mind: HSEARCH-1442 and HSEARCH-1462 but IIRC we had >> others). >> >> (Sorry for the noise but I thought it was a good opportunity to >> explain how we work, considering we're involved in this community for >> quite a long time now) >> >> -- >> Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
On 3 April 2014 13:24, Hardy Ferentschik wrote: > Hi, > > I think we dropped the ball on this one. I basically had a look at > Guillaume’s pull request. > His analysis was correct and his proposed patch brings back the old pre 4.4 > behaviour > with minimal changes. Ok that sounds good, I couldn't look at the PR yet.. should I not trust you ? :) > > There is still the question of the indented use cases of @ContainedIn. As > discussed in this thread > afaik the indent was as a sole counterpart to @IndexedEmbedded. The > implementation (probably > as a side effect) made it also work when @IndexedEmbedded was not used. This > was changed with > the metamodel refactoring where contained in was indeed treated as > counterpart of indexed embedded. > > I think we should go ahead and apply Guillaume’s pull request for 4.4 and > 4.5, basically reinstating > old 4.x behaviour, side effect or not. +1 > > The next question is then what to do in Search 5. I think we can just carry > forward the change/patch. Yes let's keep them in sync for now > I don’t think that @ContainedIn needs another attribute or that we should > introduce a whole new annotation. > @ContainedIn seems quite natural provided we documented it intend and > behaviour. Basically all what @ContainedIn > is saying, is that here we have a reference to another entity which needs > reindexing as well when the current > entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or > via a custom bridge is irrelevant. > > Thoughts? I agree with you, but in insight if this new "meaning" would have been explicit on this annotation from the beginning of time, maybe it would have had a different name? I don't think the name is appropriate for this more extended meaning; probably not a big problem but we can decide on that after it's fixed. > —Hardy > > P.S. Sanne, are you planning 4.4 and 4.5 releases as well? Just asking due to > the recent back ports. If so, we should > include this patch as well. Some of the backports I did because I indeed want to maintain these older branches, although to keep them stable I'd not be too eager on backports. We don't have dates defined, but we can certainly release these when there are enough good reasons to: for example if Guillaume needs it. Sanne > > > > > > On 28 Jan 2014, at 14:32, Guillaume Smet wrote: > >> Hi again, >> >> I posted a pull request for the 4.5 branch: >> https://github.com/hibernate/hibernate-search/pull/590 . Comments >> welcome! >> >> I included a rather large test case I have extracted from our app. >> It's simplified but I think you should get the idea by looking at it. >> >> All tests passes. >> >> FWIW, I find the new way to do it more consistent with the names of >> the methods as updateContainedInMaxDepths now does exactly what its >> name says. >> >> It would be nice if it could also be backported to 4.4.x. >> >> Glad to discuss further enhancements if needed but I think the old >> behavior should be brought back before considering any further >> enhancements/features. >> >> -- >> Guillaume >> >> On Fri, Mar 28, 2014 at 1:28 PM, Guillaume Smet >> wrote: >>> Hi Sanne, >>> >>> On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero >>> wrote: However - I might not have fully grasped this yet - but I'm thinking that this is a feature request and not a bugfix that should be hastily applied on 4.4. >>> >>> It's not a feature request. 4.4 changed this behavior. It was working >>> well with 4.3 (and every other versions before that). >>> Guillaume, I suspect you might be a happier user if you would keep using a more bleeding edge version, so to catch any such thing earlier rather than the day before you go in production. I can only promise you that the migration to 5.0 will be a nightmare if you don't follow along in small iterations :-( >>> >>> I don't think we can be more bleeding edge than us. We upgrade our >>> core framework to new versions as soon as they are released (we coded >>> https://www.artifact-listener.org/ for this purpose). That's why we >>> spend a considerable amount of time doing QA on the components we use >>> - you see a part of this work on ORM + Search but we also do it for >>> other components. You might have noticed that we are often the first >>> company out there to catch regressions. >>> >>> When we have the ability to dedicate cycles to it, we also test CR. >>> >>> But... we develop a lot of applications for a lot of customers and >>> they have different lifecycles: we can upgrade some easily and for >>> others we have to wait for the right opportunity to do it. >>> >>> All in all, we have the following policy: >>> - all the applications in development: they use the latest versions of >>> each components, except if we catch a regression when upgrading. If so >>> we try to help fix it for the next version and we upgrade ASAP; >>> - the applications in production are updated regularly for minor >>> c
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
Hi Sanne, On Thu, Apr 3, 2014 at 3:28 PM, Sanne Grinovero wrote: > We don't have dates defined, but we can certainly release these when > there are enough good reasons to: for example if Guillaume needs it. It would be nice to have an official release once we have a fix for https://hibernate.atlassian.net/browse/HSEARCH-1583 but I don't think it's a good idea to release something before that as it's a kinda annoying one too. We have moved our most advanced/tested application in terms of indexing features to 4.4 so I think we probably won't find any more regression in it as for the features we use (we can't move this app to ORM 4.3 for now due to other big changes in our core framework). We have a couple of applications running on ORM 4.3 + Search 4.5 and we don't have any problem apart from the ones we already opened. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
On 3 Jan 2014, at 15:28, Sanne Grinovero wrote: >> I think we dropped the ball on this one. I basically had a look at >> Guillaume’s pull request. >> His analysis was correct and his proposed patch brings back the old pre 4.4 >> behaviour >> with minimal changes. > > Ok that sounds good, I couldn't look at the PR yet.. should I not trust you ? > :) You definitely, should ;-) I just felt that we kind of left the discussion open ended. >> There is still the question of the indented use cases of @ContainedIn. As >> discussed in this thread >> afaik the indent was as a sole counterpart to @IndexedEmbedded. The >> implementation (probably >> as a side effect) made it also work when @IndexedEmbedded was not used. This >> was changed with >> the metamodel refactoring where contained in was indeed treated as >> counterpart of indexed embedded. >> >> I think we should go ahead and apply Guillaume’s pull request for 4.4 and >> 4.5, basically reinstating >> old 4.x behaviour, side effect or not. > > +1 Ok then >> The next question is then what to do in Search 5. I think we can just carry >> forward the change/patch. > > Yes let's keep them in sync for now > >> I don’t think that @ContainedIn needs another attribute or that we should >> introduce a whole new annotation. >> @ContainedIn seems quite natural provided we documented it intend and >> behaviour. Basically all what @ContainedIn >> is saying, is that here we have a reference to another entity which needs >> reindexing as well when the current >> entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or >> via a custom bridge is irrelevant. >> >> Thoughts? > > I agree with you, but in insight if this new "meaning" would have been > explicit on this annotation from the beginning of time, maybe it would > have had a different name? Maybe. But what? @ContainedIn kind of fits. > I don't think the name is appropriate for this more extended meaning; > probably not a big problem but we can decide on that after it's fixed. Sure. > We don't have dates defined, but we can certainly release these when > there are enough good reasons to: for example if Guillaume needs it. ok ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] CI environment
There is something very very funky going on in the CI environment. The ORM master job hangs almost every run now. Oddly, it hangs trying to compile test classes. I have tried a number of things in attempt to find out why. I have added `strace` to the job command, ssh'iong to the box and manually watching processes. None of this has illuminated the cause for me. Interestingly, I tried using Gradle's --debug option but then of course the job does not hang. OGM job (at least #110) is fubar as well. It is just sitting there spinning. The console shows absolutely nothing. Its been in that state for "Started 9 hr 48 min ago" as of the time I write this. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
