On 26 nov. 09, at 10:59, Amin Mohammed-Coleman wrote: > Hi > > So I'll make the following changes > > 1) Move fulltextfilterdef to a global settings, similar to the > Analyzer definitions. This means that SearchFactoryImpl would need > to be updated to check for not only entities for filter defs but > also in the global settings?
ok > > 2) Remove analyzerDescriminator from indexEmbedded() ok > > 3) Create a SearchMappingFactory class which returns a SearchMapping > implementation? no not yet, we are not mature. > > 4) Make SearchMapping into an interface see above > > I can have these done and with you by the end of today or tomorrow > mornign (I've got a job interview today...gulp) > > Cheers > Amin > > On Thu, Nov 26, 2009 at 8:41 AM, Emmanuel Bernard <emman...@hibernate.org > > wrote: > > On 26 nov. 09, at 09:32, Sanne Grinovero wrote: > > About 2) > 2A - fullTextFilterDef: > While it's ok for the annotation to stay on an indexed entity, I don't > see a named filter as coupled/related to an entity, shouldn't this be > part of global settings? > > Ah right, makes sense > > > > 2B - analyzerDiscriminator > yes makes sense only on an indexed entity, not on indexedembeeded as > it's being ignored on the embedded entity (currently.. improve? not to > support in API now anyway) > > ok > > > > 2C - similarity > We actually check for only one Similarity being set for a whole index > (i.e. class hierarchy), so this is not settable on indexedembedded for > sure. Actually it might make more sense on a index configuration, > rather than on an entity configuration - if you accept a mismatch in > how configuration works programmatic vs annotations. > There's an open issue already to set similarity at index level (in > addition to annotating the root type), we could consider programmatic > already improved in this sense. > > 4 - > Is date bridge exclusive to calendar bridge? I think the > contract expresses that today. > Don't know what you mean, but something is wrong here: we have a > CalendarBridge and a DateBridge. > > Cheers, > Sanne > > 2009/11/26 Emmanuel Bernard <emman...@hibernate.org>: > Hey, > Let's release Beta1 as it is except for 5 and 6 and take time to try > the API before refining it. > > On 25 nov. 09, at 17:29, Amin Mohammed-Coleman wrote: > > Hi All, > > Would it be possible get feedback with regards to points 2, 3 and > 4. I can create patch to address those issues. > > Cheers > Amin > > On Fri, Nov 20, 2009 at 2:20 PM, Emmanuel Bernard > <ebern...@redhat.com> wrote: > Hi Amin, > I've committed your patch, thanks! > There is still some work and questions remaining but that's a big > coverage improvement. Now on to the doc to get the release out :) > > Here is my raw feedback > > 1. > Interface vs class? > Should we start using interfaces instead of classes, at least for > SearchMapping. That way we could hide the getEntityDescriptor() > method to the users. > I think we need to start using superclasses or super interfaces to > enforce the repeated contracts down to the tree of navigation? > > 2. > Should the methods be on IndexedMapping not EntityMapping? > - fullTextFilterDef > - analyzerDiscriminator > - similarity > Question to Hardy and Sanne, do these concepts make sense on a non > @indexed element? I can't remember how the parser behaves. > > I think these methods should be onn IndexedMapping rather than > EntityMapping > - boost > - providedId > > The problem with this approach is that we would need to > differentiate PropertyMapping and IndexedPropertyMapping. I am not > sure this additional complexity is worth the extra help to the > developer. > > 3. > property(String name, ElementType type) should it be replaced with > specific methods like? > .field() => conflict with lucene field > .getter() > > 4. > Is date bridge exclusive to calendar bridge? I think the contract > expresses that today. > > 5. > ContainedInMapping does not contain the necessary upper methods. > > 6. > I've updated the original ProvidedIdTest, Can you push the same > changes to the programmatic version of the test. > > > _______________________________________________ > 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