NamingStrategy Enhancement
by Mike C
Hi,
I wish to implement a NamingStrategy which translates the 'id' field
of a Person entity to have a column name of 'pk_person'. I also wish
to translate boolean fields to have a column name of 'is_'+field. The
currently NamingStrategy interface does not support either of these
because it does not include class/type information in its interface.
Others have also encountered this problem:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1655
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3641
I am keen to resolve these issues. I'm willing to write a patch and
submit it, however if the concept (of passing type information to the
naming strategy) isn't acceptable then can someone tell me now so I
don't spend time writing an unused patch? (Or should I be directing
this question elsewhere?)
I realise that I can use @Column annotations or mapping files to
implement these naming conventions, but I'm keen to keep it outside of
the business model (especially since the model has about 200 tables),
and it seems like an obvious enhancement to the NamingStrategy.
Cheers,
Mike
14 years, 10 months
[BV] Path, string or object model
by Emmanuel Bernard
Please review and comment.
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel.bernard(a)jboss.com>
> Date: June 17, 2009 14:41:03 EDT
> To:
> Subject: Re: Path, string or object model
>
> Here is the solution I cooked. I think it's acceptable but add some
> complexity in the ConstraintValidatorContext API (see other email).
> Please review (pay special attention to the examples).
>
> A Path represents the path and is the one accepted by the path
> consuming APIs. A Path is an Iterable of Nodes.
>
> /**
> * Represent a navigation path from an object to another.
> * Each path element is represented by a Node.
> *
> * The path corresponds to the succession of nodes
> * in the order they are retured by the Iterator
> *
> * @author Emmanuel Bernard
> */
> public interface Path extends Iterable<Node> {
> }
>
>
> A node represent a path element.
>
> /**
> * Represents an element of a navigation path
> *
> * @author Emmanuel Bernard
> */
> public interface Node {
> /**
> * Property name the node represents
> * or null if the leaf node and representing an entity
> * (in particular the node representing the root object
> * has its name null)
> */
> String getName();
>
> /**
> * True if the node represents an object contained in an Iterable
> * or in a Map.
> */
> boolean isInIterable();
>
> /**
> * The index the node is placed in if contained
> * in an array or List. Null otherwise.
> */
> Integer getIndex();
>
> /**
> * The key the node is placed in if contained
> * in a Map. Null otherwise.
> */
> Object getKey();
> }
>
> A few interesting points:
> - the index / key is hosted by the node after the collection node
>
> Here are a few examples and their Node equivalent
>
> ""
> 0: Node(name:null, isInIterable:false, index:null, key:null)
>
> "email"
> 0: Node(name:email, isInIterable:false, index:null, key:null)
>
> "addresses"
> 0: Node(name:addresses, isInIterable:false, index:null, key:null)
>
> "addresses["home"]" represent the bean level of an Address object
> 0: Node(name:addresses, isInIterable:false, index:null, key:null)
> 1: Node(name:null, isInIterable:true, index:null, key:home)
>
> "addresses["home"].city"
> 0: Node(name:addresses, isInIterable:false, index:null, key:null)
> 1: Node(name:city, isInIterable:true, index:null, key:home)
>
> "billingAddresses[3].country.name"
> 0: Node(name:billingAddresses, isInIterable:false, index:null,
> key:null)
> 1: Node(name:country, isInIterable:true, index:3, key:null)
> 2: Node(name:name, isInIterable:false, index:null, key:null)
>
>
> ConstraintViolation renders a Path
>
> public interface ConstraintViolation<T> {
> Path getPropertyPath();
> }
>
> TraversableResolver accepts a path
>
> public interface TraversableResolver {
> boolean isReachable(Object traversableObject,
> String traversableProperty,
> Class<?> rootBeanType,
> Path pathToTraversableObject,
> ElementType elementType);
> ...
> }
>
> PS: should String traversableProperty be Node traversableProperty ?
>
>
> On May 27, 2009, at 12:19, Emmanuel Bernard wrote:
>
>> In several areas we do describe path:
>> - ConstraintViolation
>> - ConstraintValidatorContext (with addError(String, String) which
>> allows to concatenate substrings
>>
>> So far we use the notion of string to represent it
>> - address.name
>> - cards[3].color
>> - addresses["home"].city
>>
>> I have added the idea of using [] for simple Iterable objects (ie
>> non indexed, like a Set)
>> - accounts[].balance
>>
>> Anybody objects to that?
>>
>> Second point
>> Do we want to replace this String approach with a path object mode?
>>
>> http://opensource.atlassian.com/projects/hibernate/browse/BVAL-143
>> ______
>> path are today strings with dot separating properties. But it break
>> when Set or Iterable are used.
>> We could replace that with
>> --- First strawman, must evolve --
>> class PathElement {
>> String getName();
>> PathElement getParentPath();
>> boolean isIterable();
>> boolean isIndexed();
>> Object getIndex();
>> //TODO int getIndex()?
>>
>> // not happy about that as it is only useful for
>> Constraintciolation
>> PathElement getChild();
>> }
>>
>> PathElement would be used for Constraintvuilation, maybe CVContext
>> etc
>>
>> can this be refactored using inheritance + generics to have an
>> IndexedPathElement only when it matters (probably no unfortunately)
>> ______
>>
>>
>> Pros:
>> - less string manipulation by the user and the TraversableResolver
>> implementation
>> - the map index no longer rely on "[" + toString() + "]" and is
>> likely more easily handled
>>
>> Cons:
>> - ConstraintValidatorContext becomes more complex as it needs to
>> expose some kind of path element builder.
>> - we would like need to standardize some kind of String
>> serialization anyway
>> - I don't see Pros as huge advantages
>>
>> WDYT?
>
14 years, 10 months
HHH 869 (Collections of value type in the Criteria API).
by Daniel Pitts
Hello,
I'm new to the list, so please forgive me if I miss some common
netiquette that is expected on this list.
I'd like to try to create a patch to solve 869, as well as support
querying of collections of composite types.
First, are there any guidelines of what I should and shouldn't do? I'd
love to clean up the implementation of CriteriaQueryTranslator while I'm
working in there, but if that would disqualify my patch, then of course
I should avoid that ;-)
Second, I'm having a little trouble finding the metadata I need to
implement CriteriaQueryTranslator.getColumns() and
CriteriaQueryTranslator.getType() for composite collections. By that
point, I have access to: CollectionPersister, propertyName, and
sqlAlias. CollectionPersister.getElementType() returns a CompositType
that appears to be empty.
Thanks,
Daniel.
14 years, 10 months
[BV] Validation.byProvider() revisited
by Emmanuel Bernard
Hardy,
Wish #1 realized. But this has consequences:
- I broke the TCK test suite :)
- you are officially responsible to review the spec / javadoc
changes (see attached email with spec diff)
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel.bernard(a)JBOSS.COM>
> Date: June 15, 2009 23:10:33 EDT
> To: JSR-303-EG(a)JCP.ORG
> Subject: Validation.byProvider() revisited
> Reply-To: Java Community Process JSR #303 Expert List <JSR-303-EG(a)JCP.ORG
> >
>
> I never liked the idea that byProvider() was taking a Configuration
> subclass and not the actual ValidationProvider class.
> This is now fixed using some additional generics magic. It has also
> the nice side effect of simplifying the contract between the
> bootstrap module and the providers.
>
> In a nutshell, instead of
>
> ValidatorFactory factory = Validation
> .byProvider( ACMEConfiguration.class ) //chose a specific
> provider
> .configure()
> .messageInterpolator( new
> ContainerMessageInterpolator() ) //default configuration option
> .addConstraint(Address.class,
> customConstraintDescriptor) //ACME specific method
> .buildValidatorFactory();
>
> we have
>
> ValidatorFactory factory = Validation
> .byProvider( ACMEProvider.class ) //chose a specific provider
> .configure()
> .messageInterpolator( new
> ContainerMessageInterpolator() ) //default configuration option
> .addConstraint(Address.class,
> customConstraintDescriptor) //ACME specific method
> .buildValidatorFactory();
>
> The ACME provider becomes
>
> /**
> * ACME validation provider
> * Note how ACMEConfiguration and ACMEProvider are linked together
> * via the generic parameter.
> */
> public class ACMEProvider implements
> ValidationProvider<ACMEConfiguration> {
> ...
> }
>
>
> Validation.byProvider() now is
>
> /**
> * Build a <code>Configuration</code> for a particular provider
> implementation.
> * Optionally overrides the provider resolution strategy used to
> determine the provider.
> * <p/>
> * Used by applications targeting a specific provider
> programmatically.
> * <p/>
> * <pre>
> * ACMEConfiguration configuration =
> * Validation.byProvider(ACMEProvider.class)
> * .providerResolver( new MyResolverStrategy() )
> * .configure();
> * </pre>,
> * where <code>ACMEConfiguration</code> is the
> * <code>Configuration</code> sub interface uniquely identifying the
> * ACME Bean Validation provider. and ACMEProvider is the
> ValidationProvider
> * implementation of the ACME provider.
> *
> * @param providerType the <code>ValidationProvider</code>
> implementation type
> *
> * @return instance building a provider specific
> <code>Configuration</code>
> * sub interface implementation.
> */
> public static <T extends Configuration<T>, U extends
> ValidationProvider<T>>
> ProviderSpecificBootstrap<T> byProvider(Class<U> providerType) {
> [...]
> }
>
> ValidationProvider now is
>
> package javax.validation.spi;
>
> /**
> * Contract between the validation bootstrap mechanism and the
> provider engine.
> * <p/>
> * Implementations must have a public no-arg constructor. The
> construction of a provider
> * should be as "lightweight" as possible.
> *
> * <code>T</code> represents the provider specific Configuration
> subclass
> * which typically host provider's additional configuration methods.
> *
> * @author Emmanuel Bernard
> * @author Hardy Ferentschik
> */
> public interface ValidationProvider<T extends Configuration<T>> {
>
> /**
> * Returns a Configuration instance implementing <code>T</code>,
> * the <code>Configuration</code> subinterface.
> * The returned Configuration instance must use the current
> provider (<code>this</code>)
> * to build the ValidatorFactory instance.
> * <p/>
> *
> * @param state bootstrap state
> *
> * @return specific Configuration implementation
> */
> T createSpecializedConfiguration(BootstrapState state);
>
> /**
> * Returns a Configuration instance. This instance is not bound to
> * use the current provider. The choice of provider follows the
> algorithm described
> * in {@link javax.validation.Configuration}
> * <p/>
> * The ValidationProviderResolver used by <code>Configuration</code>
> * is provided by <code>state</code>.
> * If null, the default ValidationProviderResolver is used.
> *
> * @param state bootstrap state
> *
> * @return Non specialized Configuration implementation
> */
> Configuration<?> createGenericConfiguration(BootstrapState state);
>
> /**
> * Build a ValidatorFactory using the current provider
> implementation. The
> * ValidatorFactory is assembled and follows the configuration passed
> * via ConfigurationState.
> * <p>
> * The returned ValidatorFactory is properly initialized and ready
> for use.
> * </p>
> *
> * @param configurationState the configuration descriptor
> *
> * @return the instanciated ValidatorFactory
> * @throws javax.validation.ValidationException if the
> ValidatorFactory cannot be built
> */
> ValidatorFactory buildValidatorFactory(ConfigurationState
> configurationState);
> }
>
> esp, we no longer have isSuitable.
>
>
> Any objection? The diff for the spec is attached
> http://people.redhat.com/~ebernard/validation/#bootstrapping
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
14 years, 10 months
[BV] constraint level payload
by Emmanuel Bernard
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel.bernard(a)JBOSS.COM>
> Date: June 15, 2009 17:57:48 EDT
> To: JSR-303-EG(a)JCP.ORG
> Subject: Re: constraint level payload
> Reply-To: Java Community Process JSR #303 Expert List <JSR-303-EG(a)JCP.ORG
> >
>
> Done
> http://people.redhat.com/~ebernard/validation/#constraintsdefinitionimple...
>
> Pleaase have a look and let me know what you think. I'm not a big
> fan of forcing this noew attribute on everybody's constraint but I
> don't see muc more possibilities.
>
> 2.1.1.3. payload
>
> Every constraint annotation must define a payload element that
> specifies which payload the constraint declaration is associated with.
>
> Class<? extends ConstraintPayload>[] payload() default {};
> The default value must be an empty array.
>
> Each attachable payload extends ConstraintPayload.
>
> /**
> * Payload type that can be attached to a given
> * constraint declaration.
> * Payloads are typically used to carry on metadata information
> * consumed by a validation client.
> *
> * Use of payloads is not considered portable.
> *
> * @author Emmanuel Bernard
> * @author Gerhard Petracek
> */
> public interface ConstraintPayload {
> }
> Payloads are typically used by validation clients to associate some
> metadata information to a given constraint declaration. Payloads are
> typically non portable. Describing payloads as interface extensions
> as opposed to a string based approach allows an easier and more type-
> safe approach.
>
> One use case for payload shown in Example 2.1, “Use of payload to
> associate severity to a constraint” is to associate a severity to a
> constraint. This severity can be exploited by a presentation
> framework to adjust how a constraint failure is displayed.
>
> Example 2.1. Use of payload to associate severity to a constraint
>
> package com.acme.severity;
> public class Severity {
> public static class Info extends ConstraintPayload {};
> public static class Error extends ConstraintPayload {};
> }
>
> public class Address {
> @NotNull(message="would be nice if we had one",
> payload=Severity.Info.class)
> public String getZipCode() {...}
>
> @NotNull(message="the city is mandatory",
> payload=Severity.Error.class)
> String getCity() {...}
> }
> The payload information can be retrieved from error reports via
> ConstraintViolation objects (see Section 4.2, “ConstraintViolation”)
> or using the metadata API viaConstraintDescriptor objects (see
> Section 5.5, “ConstraintDescriptor”).
>
>
> On May 29, 2009, at 04:49, Emmanuel Bernard wrote:
>
>> We have had a few discussions around having a payload on
>> constraints that could be consumed by client frameworks.
>>
>> There are 4 competing solutions:
>>
>> #1 Nothing
>> The argument would be that it's not needed and hence we don't need
>> any payload.
>> On that subject what are the use cases for such a payload. Please
>> be as specific as possible.
>>
>> - We have identified Error / Warn modes which I argued can be
>> solved by groups. I also argued that groups and modes are *not*
>> orthogonal to groups and hence would not lead to a group explosion.
>> Can someone bring a real use case showing groups and modes as
>> orthogonal? (something more substantial than Group1
>>
>> - Sebastian, what were the other use cases you had in mind when
>> you wanted the @param approach
>>
>> #2 keep it open for later
>> we could reserve the "payload" or "parameter" attribute name and
>> use it for a next rev of this spec.
>>
>> #3 the string based approach
>> Sebastian's proposal
>>
>> @NotNull
>> (params
>> ={@Param(key="prio";value="1"),@Param(key="severity";value="3")})
>> String myfield;
>>
>> I personally don't like this approach as it is very verbose and
>> totally unsafe. But it has the advantage of allowing parameters
>> very easily.
>>
>> #4 the interface based approach
>>
>> (Part of) Gerhard's proposal
>>
>> interface javax.validation.ValidationParameter {}
>>
>> //framework classes
>> interface com.acme.ViolationSeverity extends ValidationParameter {
>> FacesMessage.Severity();
>> MessageType postfix();
>> }
>>
>> class com.acme.WarnSeverity implements ViolationSeverity {
>> FacesMessage.Severity() { return acesMessage.SEVERITY_WARN; }
>> MessageType postfix() { return MessageType.WARN;}
>> }
>>
>> //user code
>> @NotNull(params=WarnSeverity.class)
>>
>> Pros:
>> much cleaner on the client code
>> type safe ont he client code
>>
>> Cons:
>> much more verbose to define a new kind of parameter
>> untype safe when the value is read by the framework (so is #3)
>> ValidationParameter[] params =
>> constraintViolation.getAnnotation().params(); if (params[0]
>> instanceof ViolationSeverity) {};
>> it creates a compile time dependency on the targeted framework
>> no runtime dependency but if the framework is not here, the
>> constraint annotation will not be visible
>
14 years, 10 months
Re: [hibernate-dev] Wishing to work on Hibernate's DDL capabilities
by Steve Ebersole
1) A DML/DDL split is not going to happen. Too broad.
2) keep this discussion on list please.
On Wed, 2009-06-10 at 14:49 +0200, Francis Galiegue wrote:
> 2009/6/10 Steve Ebersole <steve(a)hibernate.org>:
> > On Tue, 2009-06-09 at 17:11 +0200, Francis Galiegue wrote:
> [...]
> >>
> >> Steven has pointed to a Jira task talking about an overhaul of the
> >> Dialect abstract class and all its derivatives, because for one, the
> >> Dialect doesn't provide "purpose oriented" capabilities, just one big
> >> lump of methods. After looking at the code (3.3.1), I can see that
> >> this is the case: for instance, there's no separation between DML and
> >> DDL.
> > Well the JIRA[1] to which I pointed you does not really go into this
> > per-se. It is more talking about potentially changing the way DDL is
> > created to use a delegate. Currently what happens is that the mapping
> > objects (Table, Index, etc) all know how to create DDL there own DDL.
> > The tie-in with Dialect here is that they coordinate with the Dialect to
> > figure out its capabilities and syntax. What I'd rather see is an
> > externalization of this DDL rendering. There are many parts to this and
> > it is in no way trivial. But the basic "externalize the DDL generation
> > code" should not be overly complex.
> >
> > I too had been considering some similar form of cleanup. The ones I had
> > considered were things like grouping together various "purpose oriented"
> > methods into componentized contracts. The ones I mentioned to you to
> > give example were the methods pertaining to a dialects IDENTITY support
> > and its sequence support. So I'd imagine something like:
> >
> > public interface IdentitySupport {
> > public boolean supportsIdentityColumns();
> > public boolean supportsInsertSelectIdentity();
> > ...
> > }
> >
> > public interface SequenceSupport {
> > public boolean supportsSequences();
> > public boolean supportsPooledSequences();
> > ...
> > }
> >
> > The Dialect contract could then be changed to return these contracts.
> > But this is all really secondary to what you want to achieve. For your
> > purposes, you are really just interested in the DDL generator piece.
> > For that I had envisioned asking the Dialect to get its DDL generation
> > delegate; maybe something like:
> > class Dialect {
> > ...
> > public DDLGenerator getDDLGenerator() {
> > return ...;
> > }
> > }
> >
> > But I never got the chance to completely think this all through. There
> > are lots of design questions that need to be addressed. Stuff like does
> > the delegate contract allow for both create/drop and alter usages? Or
> > do we ask the Dialect for a delegate for each usage? At what
> > granularity do we generate DDL commands? And if say at the granularity
> > of each Table etc, how do we account for say a table DDL command which
> > includes creating the PK versus one that does not (and therefore needs
> > separate DDL)?
> >
> > Anyway, that's about as far as I got.
> >
>
> Well, my primary interest is in DDL, admittedly, but I'm interested in
> the whole Dialect in general.
>
> I still see as necessary a distinction between DML and DDL. I imagine
> one could do such a thing as:
>
> DMLDialect dml = Dialect.getDMLDialect();
>
> if (dml.supportsWhatever()) ...
>
> I haven't had a deep enough look to separate DML from DDL usage yet.
> Most importantly, I don't know where the mechanism to generate DML
> statements is, and how it works.
>
> As to DDL itself, it is basically stateless. If it were only for me
> and my crazy usage scenario (dynamic mappings at runtime), this is the
> way I envision it:
>
> //oldcfg the old Configuration, newcfg the new Configuration - note
> that the basic settings don't change, only the mappings can change
> DDLExecutor ddlexec =
> newcfg.getDDLDialect().generateDDLExecutor(oldcfg, newcfg);
> ddlexec.before();
> // renew SessionFactory with newcfg
> ddlexec.after();
>
> The DDLDialect would have a TableSupport, ColumnSupport,
> SequenceSupport, IdentityColumnSupport, IndexSupport..., and the
> .buildExecutor() would generate a DDLExecutor object (an interface,
> really) with DDL statements that must be executed before renewal of
> the SessionFactory (.before()), because it has been detected that DDL
> changes between oldcfg and newcfg _would_ affect existing Sessions,
> and DDL statements that can be postponed until only after the new
> SessionFactory has ben spawned.
>
> The .generateDDLExecutor would then be in charge of detecting changes
> and call upon the appropriate subdialects (it would call the
> appropriate DDL "fragments", say, IndexSupport if it sees that an
> index must be added/removed) and generate the appropriate scripts and
> fill the DDLExecutor with said scripts (the ones that must be executed
> before the SessionFactory renewal and the ones that may be delayed
> until after it has been spawned).
>
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
14 years, 10 months
Re: New stuff with HS
by Emmanuel Bernard
hey
On Jun 11, 2009, at 09:52, Navin Surtani wrote:
> Heya guys,
>
> Hope all's going well with you ...
>
> Was speaking to Manik about what needs to be done with Infinispan -
> not been doing any work on this for a while since I've had exams
> which are done now - and he was just telling me that you guys are
> working on abstracting HS from Core?
hum no, it's done, that's the work you have done basically.
Something can likely be done to abstract some of the query engine but
I'm not sure how much. This needs ot be experimented.
>
> Emmanuel: Manik told me that you guys spoke about this and that you
> both seem to want to use Lucene for Infinispan. I was hoping to have
> an idea about what you guys spoke about and also figure out how we
> should implement this.
The idea is to get the infinispan data indexed in Lucene and stored...
well in Lucene as well. HSearch would be the query engine of Infinispan.
One question was whether or not create a JPA-QL / JPA2 Criteria API
layer on top of Lucene queries at least for non join or simple join
queries. It's an orthogonal project though.
The idea was to index the local data (node-wise). We can call each
node to get a global result (we will need to adjust Hibernate Search
in this area as we only do local IndexReaders today but AFAIK that's
doable).
The hard problem to crack is how Hibernate Search will deduplicate the
results. Infinispan does partly duplicate data, hence the query will
return the same data several times.
>
> For the core changes in the query interface I picked out these 3
> main changes in order of importance: -
>
> 1 - What's new with Hibernate Search and it's backend. Also how we
> can work it into Infinispan. I imagine we take a similar plan of
> attack as we did with JBCS.
Not much that will impact you. We have a new backend that is JGroups
based. sow e have lucene, JMs and JGroups now.
>
> 2 - Use of interceptors within Infinispan as opposed to listeners
> with JBCS.
not sure what's the fundamental difference so OK :)
>
> 3 - Editions within the query/searchable module of Infinispan that
> take into account the new API.
>
yes
> So if you guys could tell me what's new, or tell me where to go look
> for stuff (blogs, wikis etc) that would be great.
One thing we are working on is massive indexing. Sanne can talk more
about that but I frankly don't think that will impact infinispan in
the near term.
The rest was under the hood optimizations and some cool new higher
level features.
>
> In terms of what's new, do you guys have any major changes to
> backend/API?
nope but I think that would be a good time to:
- think about sharing some of the search infrastructure
(FullTextQueryImpl has some reusable stuffs likely)
- rethink the query API after hearing feedback from users. (I was
not 100% happy with the JBCS API)
>
> Thanks plenty,
> Navin.
>
>
>
14 years, 10 months
Using hiberate with DB2 Stored Procedures
by McDowell, Paula
Hi, all. I'm new to hibernate, and I'm having a hard time finding examples on how to define a mapping for a stored procedure. I'm mainly confused on the "call" portion.
<sql-query name="GETFUNDINGTYPES" callable="true">
<return alias= "getFundingTypes" class="FundingType">
<return-property name="code" column="CODE"/>
<return-property name="description" column="DESCRIPTION"/>
<return-property name="createTS" column="CREATE_TS"/>
</return>
{? = call GETFUNDINGTYPES ()}
</sql-query>
It may sound silly, but I need to understand the relevance of the "?" 's. I'm returning all the columns in the table, so I've listed all three as return properties. (CODE, DESCRIPTION, CREATE_TS)
1. What goes in the method call parens? Is it the number of input/output that the DB2 stored procedure has defined? Or is it the number of return properties, ie GETFUNDINGTYPES(?,?,?); one '?' for each return property listed. Or do I leave it empty as I have done above since I've already listed the return properties?
2. What does the '?' to the left of the '=' mean? Is it the number of actual results? If that is true, then is it always one '?' to signify one result set?
Any help that anyone can provide is greatly appreciated.
Thank you,
Paula
Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender.
14 years, 10 months
Re: [hibernate-dev] HSearch: Using sharding and avoiding query on multiple shards
by Emmanuel Bernard
On Jun 10, 2009, at 15:22, Chase Seibert wrote:
> >That sounds like an elegant approach but we need a way to make it
> easy to declare
> >a filter as dump/shard-sensitive only (ie not force the user to
> write some Filter
> >implementation). With this knowledge, HSearch could ignore the dump
> filter for
> >the actual Lucene filtering operation.
>
> I actually think it's rather elegant, because it's backwards
> compatible. The filter will cause the correct data to return whether
> it's executed before or after hitting the indexes. Ie, it returns
> the correct results pre-patch.
>
> To avoid the extra over-head, would it be safe to assume that if the
> IndexShardingStrategy returned a subset (non-zero, non-all) set of
> DirectoryProviders for
> getDirectoryProvidersForQuery(FullTextFilter[] filters), that it's
> safe to ignore that filter post-search? Effectively, we can delete
> that filter from the array in FullTextQueryImpl.
No, that would not be safe.
I'd rather get a special marker (flag or class) to specify that a
filter should be ignored from the list post search.
14 years, 10 months
