Re: [hibernate-dev] [Hibernate Search] Feedback on Document Field lazy loading
Chances are that if you need to use exactly the field name, using a TwoWayStringBridge is what you need. On Jun 16, 2008, at 04:20, Hardy Ferentschik wrote: On Sun, 15 Jun 2008 18:22:22 +0200, Emmanuel Bernard [EMAIL PROTECTED] wrote: I am not sure if I like lazy field loading in the second case. The proposed metadata to FieldBridge (FieldBridge.fieldNameStrategy() EXACT, IN_NAMESPACE, NON_SAFE) seems very artificial. If we extend the FieldBridge interface why not just add a new methods getFieldNames() which returns a array of String listing all field names this bridge is using? I thought about that but you don't always know :) Thing Maps mapped with the key as the field name. True, but that is really an exceptional case. In most cases the added field names will be constant, otherwise it is damn hard to write a query. getFieldNames(String name) could return null in case the field names are dynamic. The API is not 100% intuative this way, but I think I still would prefer a explicit list of field names over a enum type like EXACT, IN_NAMESPACE or NON_SAFE. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Hibernate Search] Feedback on Document Field lazy loading
On Sun, 15 Jun 2008 18:22:22 +0200, Emmanuel Bernard [EMAIL PROTECTED] wrote: I am not sure if I like lazy field loading in the second case. The proposed metadata to FieldBridge (FieldBridge.fieldNameStrategy() EXACT, IN_NAMESPACE, NON_SAFE) seems very artificial. If we extend the FieldBridge interface why not just add a new methods getFieldNames() which returns a array of String listing all field names this bridge is using? I thought about that but you don't always know :) Thing Maps mapped with the key as the field name. True, but that is really an exceptional case. In most cases the added field names will be constant, otherwise it is damn hard to write a query. getFieldNames(String name) could return null in case the field names are dynamic. The API is not 100% intuative this way, but I think I still would prefer a explicit list of field names over a enum type like EXACT, IN_NAMESPACE or NON_SAFE. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Hibernate Search] Feedback on Document Field lazy loading
what is your goal? performance? from the code I guess you don't intend to support something like setProjection( FullTextQuery.DOCUMENT, lastname ); as you skip fieldnames processing when you hit DOCUMENT; I agree with you it would be a bit stupid, but someone could want to do that for some purpose. I generally don't like the return types as arrays very much, it would be very cool to get anyway an entity containing only the projected data (a sort of extremely-lazy state) but I guess it would introduce a lot of other problems. (overwrite and possibly change contained data when (eventually) really loaded from DB?) What if you would permit uses to pass their own DocumentExtractor, impl to return a wrapping object? This is what we do in the library system ( we just use Search to build Documents, not for searching them), depending on the page view I know which fields I want to show and have a simple bean to link to JSF, so I iterate on results and produce a list of beans with my own pluggable logic, using a different one each time depending on the data need. org.hibernate.search.FullTextQuery hibQuery = s.createFullTextQuery( query, Employee.class ); DocumentExtractor dt = new EmployeeDocToFullnameExtractor(); hibQuery.setProjection( dt ); and nothing stops you to support some syntax as hibQuery.setProjection( FullTextQuery.THIS, FullTextQuery.SCORE, dt ); even if it is obviously redundant. IMHO you move the responsability of managing weird fieldbridges to the users this way... Sanne 2008/6/14 Emmanuel Bernard [EMAIL PROTECTED]: I played around the idea of not loading unnecessary fields when loading a Lucene document. It turns out this is not easily possible http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-213 I would appreciate feedback in JIRA on this one. -- Emmanuel Bernard [EMAIL PROTECTED] http://in.relation.to http://blog.emmanuelbernard.com http://twitter.com/emmanuelbernard ___ 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] [Hibernate Search] Feedback on Document Field lazy loading
On Jun 15, 2008, at 04:24, Sanne Grinovero wrote: what is your goal? performance? Performance, memory consumption, reduce the gap between entity loading and projection from a perf point of view (assuming projection loads the same amount of data). from the code I guess you don't intend to support something like setProjection( FullTextQuery.DOCUMENT, lastname ); No, if you want a Document, you want it all most likely, otherwise a simple field projection will do it better and benefit from the fields. as you skip fieldnames processing when you hit DOCUMENT; I agree with you it would be a bit stupid, but someone could want to do that for some purpose. I generally don't like the return types as arrays very much, it would be very cool to get anyway an entity containing only the projected data (a sort of extremely-lazy state) but I guess it would introduce a lot of other problems. (overwrite and possibly change contained data when (eventually) really loaded from DB?) We had this goal in mind from day one (Vincent had actually). But this leads to a lot of problems including non unicity, the need to use bytecode enhancement etc. We can start a separate thread but we have more valuable features on the table before this one. What if you would permit uses to pass their own DocumentExtractor, impl to return a wrapping object? This is what we do in the library system ( we just use Search to build Documents, not for searching them), depending on the page view I know which fields I want to show and have a simple bean to link to JSF, so I iterate on results and produce a list of beans with my own pluggable logic, using a different one each time depending on the data need. setProjection + a result transformer do that for you already feature wise ftQuery.setProjection(firstname, lastname).setResultTransformer(new AliasToBeanResultTransformer(PersonView.class) ); org.hibernate.search.FullTextQuery hibQuery = s.createFullTextQuery( query, Employee.class ); DocumentExtractor dt = new EmployeeDocToFullnameExtractor(); hibQuery.setProjection( dt ); and nothing stops you to support some syntax as hibQuery.setProjection( FullTextQuery.THIS, FullTextQuery.SCORE, dt ); even if it is obviously redundant. IMHO you move the responsability of managing weird fieldbridges to the users this way... you mean in your solution or in mine? Sanne 2008/6/14 Emmanuel Bernard [EMAIL PROTECTED]: I played around the idea of not loading unnecessary fields when loading a Lucene document. It turns out this is not easily possible http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-213 I would appreciate feedback in JIRA on this one. -- Emmanuel Bernard [EMAIL PROTECTED] http://in.relation.to http://blog.emmanuelbernard.com http://twitter.com/emmanuelbernard ___ 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
