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 :
> > On Tue, 2009-06-09 at 17:11 +0200, Francis Galiegue wrote:
> [...]
> >>
> >> Steven has pointed to a Jira task
On Jun 3, 2009, at 13:27, Sanne Grinovero wrote:
I am having a similar need in these days; this should be a very useful
feature, but I'd like more something I could use with the existing API
like
enableFullTextFilter
( "MyShardsSelectionStrategy" ).setParameter( ... )
a practical example:
en
Hi Lukasz,
I've been looking into your code; I have some comments but please
forgive me as I don't have any real experience about JGroups, so I'll
only tell you how much I see this code fit into Hibernate Search.
1) The maven dependency upon JGroups should probably be of type
"optional", so please
I like the patch, we can apply a slightly modified version of it.
A few comments:
* In private DirectoryProvider[]
getDirectoryProviders(DocumentBuilderIndexedEntity builder)
if ( directoryProviders != null && directoryProviders.length > 0 )
return directoryProviders;
What's the reasonin
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
you're right we need some way to know which filters don't need to be
applied on the "lowlevel" IndexSearcher,
but adding a flag breaks backwards compatibility, and using a type
will get us to use ugly "instanceof"; they're not
bad solutions but what do you think of using a new option of the
@FullTe
Here is the patch I've applied. It's mainly the same one but varies in subtle ways. I've also expanded the doc. I'll let you check it out.What I have *not* done is a "unit" test actually indexing data and searching the data based on the filter making sure only the targeted shard(s) are used (ie use
On Jun 10, 2009, at 19:12, Sanne Grinovero wrote:
you're right we need some way to know which filters don't need to be
applied on the "lowlevel" IndexSearcher,
but adding a flag breaks backwards compatibility, and using a type
We're breaking backward compatibility by changing the
IndexShar
Splitting out dml/ddl so one could build something like a "structural
compare of configurations" to create a better
migration would be interesting; though I really don't believe dynamic
mappings that also dynamically decided
the db-layout and statements is going to be more than a quick
prototypi
