Re: [jira] [Comment Edited] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-03-04 Thread Michael Sokolov 
Perhaps Robert is a fan of Object.clone()

On Feb 28, 2018 9:59 AM, "Bruno Roustant (JIRA)"  wrote:

>
> [ https://issues.apache.org/jira/browse/LUCENE-8159?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16380407#comment-16380407 ]
>
> Bruno Roustant edited comment on LUCENE-8159 at 2/28/18 2:58 PM:
> -
>
> [~rcmuir] could you be a little more explicit?
>
> Without context I don't understand why a copy constructor is bad in Java
> in general.
>
> Do you mean you prefer a copy method?
>
> PrefixQuery copy(String field)
>
>
> was (Author: bruno.roustant):
> [~rcmuir] could you be a little more explicit?
>
> Without context I don't understand why a copy constructor is bad in Java
> in general.
>
> > Add a copy constructor in AutomatonQuery to copy directly the compiled
> automaton
> > 
> 
> >
> > Key: LUCENE-8159
> > URL: https://issues.apache.org/jira/browse/LUCENE-8159
> > Project: Lucene - Core
> >  Issue Type: Improvement
> >  Components: core/search
> >Affects Versions: trunk
> >Reporter: Bruno Roustant
> >Assignee: David Smiley
> >Priority: Major
> > Attachments: 0001-Add-a-copy-constructor-
> in-AutomatonQuery-to-copy-dir.patch, LUCENE-8159.patch
> >
> >
> > When the query is composed of multiple AutomatonQuery with the same
> automaton and which target different fields, it is much more efficient to
> reuse the already compiled automaton by copying it directly and just
> changing the target field.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Comment Edited] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-28 Thread Bruno Roustant (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380407#comment-16380407
 ] 

Bruno Roustant edited comment on LUCENE-8159 at 2/28/18 2:58 PM:
-

[~rcmuir] could you be a little more explicit?

Without context I don't understand why a copy constructor is bad in Java in 
general.

Do you mean you prefer a copy method?

PrefixQuery copy(String field)


was (Author: bruno.roustant):
[~rcmuir] could you be a little more explicit?

Without context I don't understand why a copy constructor is bad in Java in 
general.

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-27 Thread Bruno Roustant (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378373#comment-16378373
 ] 

Bruno Roustant edited comment on LUCENE-8159 at 2/27/18 11:29 AM:
--

{quote}I's rather like to expose an expert constructor that takes a compiled 
automaton and expect users to compile the automaton themselves if they plan to 
reuse it in multiple queries?
{quote}
I can speak as such a "user" as I'm having this use case. We often build 
queries with the same prefix/wildcard query for multiple different fields (and 
sometimes many fields - in this case the optimization does help). As a user I 
really appreciate to simply copy a PrefixQuery or WildcardQuery, rather than 
building the automaton myself. The inner automaton inside PrefixQuery is 
hidden, and the logic is internal to the PrefixQuery. I don't want to know 
myself how it is built.

I agree with exposing the compiled automaton. But I still think PrefixQuery and 
WildcardQuery would benefit from a new constructor. And this constructor cannot 
really take any automaton as parameter, it could potentially break the 
prefix/wildcard contract. So, to me, PrefixQuery and WildcardQuery should have 
their copy constructor.
{quote}Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?
{quote}
I indeed prepared the same copy constructors for these classes. I didn't have 
time to resubmit the patch yet, but that's the idea, yes.


was (Author: bruno.roustant):
{quote}I's rather like to expose an expert constructor that takes a compiled 
automaton and expect users to compile the automaton themselves if they plan to 
reuse it in multiple queries?
{quote}
I can speak as such a "user" as I'm having this use case. We often build 
queries with the same prefix/wildcard query for multiple different fields (and 
sometimes many fields - in this case the optimization does help). As a user I 
really appreciate to simply copy a PrefixQuery or WildcardQuery, rather than 
building the automaton myself. The inner automaton inside PrefixQuery is 
hidden, and the logic is internal to the PrefixQuery. I don't want to know 
myself how it is built.

I agree with exposing the compiled automaton.
{quote}Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?
{quote}
I indeed prepared the same copy constructors for these classes. I didn't have 
time to resubmit the patch yet, but that's the idea, yes.

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-27 Thread Bruno Roustant (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378373#comment-16378373
 ] 

Bruno Roustant edited comment on LUCENE-8159 at 2/27/18 10:44 AM:
--

{quote}I's rather like to expose an expert constructor that takes a compiled 
automaton and expect users to compile the automaton themselves if they plan to 
reuse it in multiple queries?
{quote}
I can speak as such a "user" as I'm having this use case. We often build 
queries with the same prefix/wildcard query for multiple different fields (and 
sometimes many fields - in this case the optimization does help). As a user I 
really appreciate to simply copy a PrefixQuery or WildcardQuery, rather than 
building the automaton myself. The inner automaton inside PrefixQuery is 
hidden, and the logic is internal to the PrefixQuery. I don't want to know 
myself how it is built.

I agree with exposing the compiled automaton.
{quote}Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?
{quote}
I indeed prepared the same copy constructors for these classes. I didn't have 
time to resubmit the patch yet, but that's the idea, yes.


was (Author: bruno.roustant):
{quote}I's rather like to expose an expert constructor that takes a compiled 
automaton and expect users to compile the automaton themselves if they plan to 
reuse it in multiple queries?
{quote}
I can speak as such a "user" as I'm having this use case. We often build 
queries with the same prefix/wildcard query for multiple different fields (and 
sometimes many fields). As a user I really appreciate to simply copy a 
PrefixQuery or WildcardQuery, rather than building the automaton myself. The 
inner automaton inside PrefixQuery is hidden, and the logic is internal to the 
PrefixQuery. I don't want to know myself how it is built.

I agree with exposing the compiled automaton.
{quote}Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?
{quote}
I indeed prepared the same copy constructors for these classes. I didn't have 
time to resubmit the patch yet, but that's the idea, yes.

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-27 Thread Bruno Roustant (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378373#comment-16378373
 ] 

Bruno Roustant edited comment on LUCENE-8159 at 2/27/18 10:42 AM:
--

{quote}I's rather like to expose an expert constructor that takes a compiled 
automaton and expect users to compile the automaton themselves if they plan to 
reuse it in multiple queries?
{quote}
I can speak as such a "user" as I'm having this use case. We often build 
queries with the same prefix/wildcard query for multiple different fields (and 
sometimes many fields). As a user I really appreciate to simply copy a 
PrefixQuery or WildcardQuery, rather than building the automaton myself. The 
inner automaton inside PrefixQuery is hidden, and the logic is internal to the 
PrefixQuery. I don't want to know myself how it is built.

I agree with exposing the compiled automaton.
{quote}Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?
{quote}
I indeed prepared the same copy constructors for these classes. I didn't have 
time to resubmit the patch yet, but that's the idea, yes.


was (Author: bruno.roustant):
{quote}I's rather like to expose an expert constructor that takes a compiled 
automaton and expect users to compile the automaton themselves if they plan to 
reuse it in multiple queries?
{quote}
I can speak as such a "user" as I'm having this use case. We often build 
queries with the same prefix/wildcard query for multiple different fields (and 
sometimes many fields). As a user I really appreciate to simply copy a 
PrefixQuery or WildcardQuery, rather than building the automaton myself. The 
inner automaton inside PrefixQuery is hidden, and the logic is internal to the 
PrefixQuery. I don't want to know myself how it is built.

I agree with exposing the compiled automaton. Although I find the copy 
constructor easier to use.
{quote}Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?
{quote}
I indeed prepared the same copy constructors for these classes. I didn't have 
time to resubmit the patch yet, but that's the idea, yes.

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org