You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Paul Cowan (JIRA)" <ji...@apache.org> on 2008/01/30 11:09:35 UTC
[jira] Created: (LUCENE-1162) Improve architecture of
FieldSortedHitQueue
Improve architecture of FieldSortedHitQueue
-------------------------------------------
Key: LUCENE-1162
URL: https://issues.apache.org/jira/browse/LUCENE-1162
Project: Lucene - Java
Issue Type: Improvement
Components: Query/Scoring
Affects Versions: 2.3
Reporter: Paul Cowan
Priority: Minor
Per the discussion (quite some time ago) on issue LUCENE-806, I'd like to propose an architecture change to the way FieldSortedHitQueue works, and in particular the way it creates SortComparatorSources. I think (I hope) that anyone who looks at the FSHQ code will agree that the class does a lot and much of it's repetitive stuff that really has no business being in that class.
I am about to attach a patch which, in and of itself, doesn't really achieve much that's concrete but does tidy things up a great deal and makes it easier to plug in different behaviours. I then have a subsequent patch which provides a fairly simple and flexible example of how you might replace an implementation, in this case the field-local-String-comparator version from LUCENE-806.
The downside to this patch is that it involved changing the signature of SortComparatorSource.newComparator to take a Locale. There would be ways around this (letting FieldSortedHitQueue take in either a SortComparatorSource or some new, improved interface which takes a Locale (and possibly extends SortComparatorSource). I'm open to this but personally I think that the Locale version makes sense and would suggest that the code would be nicer by breaking the API (and hence targeting this to, presumably, 3.0 at a minimum).
This code does not include specific tests (I will add these, if people like the general idea I'm proposing here) but all current tests pass with this change.
Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1162) Improve architecture of
FieldSortedHitQueue
Posted by "Paul Cowan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Cowan updated LUCENE-1162:
-------------------------------
Attachment: lucene-fshq-restructure.patch
Attached lucene-fshq-restructure.patch -- this cleans up the architecture of FSHQ with no real functional changes. Example of how this might be used for LUCENE-806 to follow.
> Improve architecture of FieldSortedHitQueue
> -------------------------------------------
>
> Key: LUCENE-1162
> URL: https://issues.apache.org/jira/browse/LUCENE-1162
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Query/Scoring
> Affects Versions: 2.3
> Reporter: Paul Cowan
> Priority: Minor
> Attachments: lucene-fshq-restructure.patch
>
>
> Per the discussion (quite some time ago) on issue LUCENE-806, I'd like to propose an architecture change to the way FieldSortedHitQueue works, and in particular the way it creates SortComparatorSources. I think (I hope) that anyone who looks at the FSHQ code will agree that the class does a lot and much of it's repetitive stuff that really has no business being in that class.
> I am about to attach a patch which, in and of itself, doesn't really achieve much that's concrete but does tidy things up a great deal and makes it easier to plug in different behaviours. I then have a subsequent patch which provides a fairly simple and flexible example of how you might replace an implementation, in this case the field-local-String-comparator version from LUCENE-806.
> The downside to this patch is that it involved changing the signature of SortComparatorSource.newComparator to take a Locale. There would be ways around this (letting FieldSortedHitQueue take in either a SortComparatorSource or some new, improved interface which takes a Locale (and possibly extends SortComparatorSource). I'm open to this but personally I think that the Locale version makes sense and would suggest that the code would be nicer by breaking the API (and hence targeting this to, presumably, 3.0 at a minimum).
> This code does not include specific tests (I will add these, if people like the general idea I'm proposing here) but all current tests pass with this change.
> Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Closed: (LUCENE-1162) Improve architecture of
FieldSortedHitQueue
Posted by "Mark Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Miller closed LUCENE-1162.
-------------------------------
Resolution: Fixed
this class is deprecated
> Improve architecture of FieldSortedHitQueue
> -------------------------------------------
>
> Key: LUCENE-1162
> URL: https://issues.apache.org/jira/browse/LUCENE-1162
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Query/Scoring
> Affects Versions: 2.3
> Reporter: Paul Cowan
> Priority: Minor
> Attachments: lucene-fshq-restructure.patch, lucene-threadlocal.patch
>
>
> Per the discussion (quite some time ago) on issue LUCENE-806, I'd like to propose an architecture change to the way FieldSortedHitQueue works, and in particular the way it creates SortComparatorSources. I think (I hope) that anyone who looks at the FSHQ code will agree that the class does a lot and much of it's repetitive stuff that really has no business being in that class.
> I am about to attach a patch which, in and of itself, doesn't really achieve much that's concrete but does tidy things up a great deal and makes it easier to plug in different behaviours. I then have a subsequent patch which provides a fairly simple and flexible example of how you might replace an implementation, in this case the field-local-String-comparator version from LUCENE-806.
> The downside to this patch is that it involved changing the signature of SortComparatorSource.newComparator to take a Locale. There would be ways around this (letting FieldSortedHitQueue take in either a SortComparatorSource or some new, improved interface which takes a Locale (and possibly extends SortComparatorSource). I'm open to this but personally I think that the Locale version makes sense and would suggest that the code would be nicer by breaking the API (and hence targeting this to, presumably, 3.0 at a minimum).
> This code does not include specific tests (I will add these, if people like the general idea I'm proposing here) but all current tests pass with this change.
> Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1162) Improve architecture of
FieldSortedHitQueue
Posted by "Paul Cowan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Cowan updated LUCENE-1162:
-------------------------------
Attachment: lucene-threadlocal.patch
Attaching patch (lucene-threadlocal.patch) which serves as an example for how the previous patch might be built-upon to provide improvements or pluggable functionality. This is a fix for LUCENE-806 (the need to use ThreadLocal Comparators for sorting performance); it provides a replacement implementation of StringComparatorSource. Enabling this functionality would be as simple as:
FieldSortedHitQueue.registerComparatorSource(SortField.STRING, new ThreadLocalStringComparatorSource());
and the new behaviour would kick in, relatively seamlessly.
Note that this patch includes a new version of StringComparatorSource, which replaces the one from the previous patch.
I will attach this to LUCENE-806 as well for discussion on that end.
> Improve architecture of FieldSortedHitQueue
> -------------------------------------------
>
> Key: LUCENE-1162
> URL: https://issues.apache.org/jira/browse/LUCENE-1162
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Query/Scoring
> Affects Versions: 2.3
> Reporter: Paul Cowan
> Priority: Minor
> Attachments: lucene-fshq-restructure.patch, lucene-threadlocal.patch
>
>
> Per the discussion (quite some time ago) on issue LUCENE-806, I'd like to propose an architecture change to the way FieldSortedHitQueue works, and in particular the way it creates SortComparatorSources. I think (I hope) that anyone who looks at the FSHQ code will agree that the class does a lot and much of it's repetitive stuff that really has no business being in that class.
> I am about to attach a patch which, in and of itself, doesn't really achieve much that's concrete but does tidy things up a great deal and makes it easier to plug in different behaviours. I then have a subsequent patch which provides a fairly simple and flexible example of how you might replace an implementation, in this case the field-local-String-comparator version from LUCENE-806.
> The downside to this patch is that it involved changing the signature of SortComparatorSource.newComparator to take a Locale. There would be ways around this (letting FieldSortedHitQueue take in either a SortComparatorSource or some new, improved interface which takes a Locale (and possibly extends SortComparatorSource). I'm open to this but personally I think that the Locale version makes sense and would suggest that the code would be nicer by breaking the API (and hence targeting this to, presumably, 3.0 at a minimum).
> This code does not include specific tests (I will add these, if people like the general idea I'm proposing here) but all current tests pass with this change.
> Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org