[jira] Created: (ESPER-418) Statement fails to compile if the statement only has a where-clause and uses an alias

View: New views
5 Messages — Rating Filter:   Alert me  

[jira] Created: (ESPER-418) Statement fails to compile if the statement only has a where-clause and uses an alias

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Statement fails to compile if the statement only has a where-clause and uses an alias
-------------------------------------------------------------------------------------

                 Key: ESPER-418
                 URL: http://jira.codehaus.org/browse/ESPER-418
             Project: Esper
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.2
            Reporter: Thomas Bernhardt
            Priority: Minor
             Fix For: 4.0 - requires JDK6


Hello

I am using version 3.2.0 of Esper and have found what appears to be a bug in
the way that the EPL is being compiled.

I am using a very simple POJO as a test object with the following fields all
with respective getter and setters.

public class SimpleEvent
{
    private String uuid;
    private Integer sourceId;
    private Integer protocolId;
}

The following statement fails to register because it cannot find
"A0.sourceId"

select * from Event as A0 where A0.sourceId = 3

The problem appears to be in the optimization that is done in
StatementLifecycleSvcImpl.compile(...) at line 784.

the comment is as follows
// If not using a join and not specifying a data window, make the
where-clause, if present, the filter of the stream

What it is doing is if there are no joins and no windows defined it assumes
that it can move the where clause up and use it as a filter.  It does this
naively here

810:    FilterStreamSpecRaw streamSpec = (FilterStreamSpecRaw)
spec.getStreamSpecs().get(0);
811:
streamSpec.getRawFilterSpec().getFilterExpressions().add(whereClause);

the problem is that by simple copying that up you end up with the following
query.

select * from Event( A0.sourceId = 3 ) as A0

this optimization makes the statement invalid because it is trying to
reference that A0 before it is defined.

In order to be able to make that level of optimization it would have to
check whether or not any of the properties in the where clause is referenced
by an alias and then if it is either remove the reference to the alias or
not make the optimization in that case.  However otherwise this prevents
what should be a valid statement from being able to compile.

I have included a simple test case that will show the problem.  it attempts
to register 3 queries.  Two valid queries that are similar and the above
query.

"select * from Event where sourceId = protocolId"        //passes - because
there is no stream name
"select * from Event as E_A1 where E_A1.sourceId = E_A1.protocolId"      
//FAILS
"select * from Event.win:length(4) as E_A1 where E_A1.protocolId =
E_A1.sourceId"        //passes - because there is a window defined

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



[jira] Commented: (ESPER-418) Statement fails to compile if the statement only has a where-clause and uses an alias

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


    [ http://jira.codehaus.org/browse/ESPER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197147#action_197147 ]

Thomas Bernhardt commented on ESPER-418:
----------------------------------------

Sample code:

        EPServiceProvider engine = EPServiceProviderManager.getDefaultProvider();
        Map<String, Object> type = new HashMap<String, Object>();
        type.put("sourceId", int.class);
        engine.getEPAdministrator().getConfiguration().addEventType("ABC", type);
        engine.getEPAdministrator().createEPL("select * from ABC as s1 where s1.sourceId = 3");

==> fails to compile

> Statement fails to compile if the statement only has a where-clause and uses an alias
> -------------------------------------------------------------------------------------
>
>                 Key: ESPER-418
>                 URL: http://jira.codehaus.org/browse/ESPER-418
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>            Reporter: Thomas Bernhardt
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>
> Hello
> I am using version 3.2.0 of Esper and have found what appears to be a bug in
> the way that the EPL is being compiled.
> I am using a very simple POJO as a test object with the following fields all
> with respective getter and setters.
> public class SimpleEvent
> {
>     private String uuid;
>     private Integer sourceId;
>     private Integer protocolId;
> }
> The following statement fails to register because it cannot find
> "A0.sourceId"
> select * from Event as A0 where A0.sourceId = 3
> The problem appears to be in the optimization that is done in
> StatementLifecycleSvcImpl.compile(...) at line 784.
> the comment is as follows
> // If not using a join and not specifying a data window, make the
> where-clause, if present, the filter of the stream
> What it is doing is if there are no joins and no windows defined it assumes
> that it can move the where clause up and use it as a filter.  It does this
> naively here
> 810:    FilterStreamSpecRaw streamSpec = (FilterStreamSpecRaw)
> spec.getStreamSpecs().get(0);
> 811:
> streamSpec.getRawFilterSpec().getFilterExpressions().add(whereClause);
> the problem is that by simple copying that up you end up with the following
> query.
> select * from Event( A0.sourceId = 3 ) as A0
> this optimization makes the statement invalid because it is trying to
> reference that A0 before it is defined.
> In order to be able to make that level of optimization it would have to
> check whether or not any of the properties in the where clause is referenced
> by an alias and then if it is either remove the reference to the alias or
> not make the optimization in that case.  However otherwise this prevents
> what should be a valid statement from being able to compile.
> I have included a simple test case that will show the problem.  it attempts
> to register 3 queries.  Two valid queries that are similar and the above
> query.
> "select * from Event where sourceId = protocolId"        //passes - because
> there is no stream name
> "select * from Event as E_A1 where E_A1.sourceId = E_A1.protocolId"      
> //FAILS
> "select * from Event.win:length(4) as E_A1 where E_A1.protocolId =
> E_A1.sourceId"        //passes - because there is a window defined

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



[jira] Commented: (ESPER-418) Statement fails to compile if the statement only has a where-clause and uses an alias

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


    [ http://jira.codehaus.org/browse/ESPER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197148#action_197148 ]

Thomas Bernhardt commented on ESPER-418:
----------------------------------------

Workaround is to remove the stream alias.

> Statement fails to compile if the statement only has a where-clause and uses an alias
> -------------------------------------------------------------------------------------
>
>                 Key: ESPER-418
>                 URL: http://jira.codehaus.org/browse/ESPER-418
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>            Reporter: Thomas Bernhardt
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>
> Hello
> I am using version 3.2.0 of Esper and have found what appears to be a bug in
> the way that the EPL is being compiled.
> I am using a very simple POJO as a test object with the following fields all
> with respective getter and setters.
> public class SimpleEvent
> {
>     private String uuid;
>     private Integer sourceId;
>     private Integer protocolId;
> }
> The following statement fails to register because it cannot find
> "A0.sourceId"
> select * from Event as A0 where A0.sourceId = 3
> The problem appears to be in the optimization that is done in
> StatementLifecycleSvcImpl.compile(...) at line 784.
> the comment is as follows
> // If not using a join and not specifying a data window, make the
> where-clause, if present, the filter of the stream
> What it is doing is if there are no joins and no windows defined it assumes
> that it can move the where clause up and use it as a filter.  It does this
> naively here
> 810:    FilterStreamSpecRaw streamSpec = (FilterStreamSpecRaw)
> spec.getStreamSpecs().get(0);
> 811:
> streamSpec.getRawFilterSpec().getFilterExpressions().add(whereClause);
> the problem is that by simple copying that up you end up with the following
> query.
> select * from Event( A0.sourceId = 3 ) as A0
> this optimization makes the statement invalid because it is trying to
> reference that A0 before it is defined.
> In order to be able to make that level of optimization it would have to
> check whether or not any of the properties in the where clause is referenced
> by an alias and then if it is either remove the reference to the alias or
> not make the optimization in that case.  However otherwise this prevents
> what should be a valid statement from being able to compile.
> I have included a simple test case that will show the problem.  it attempts
> to register 3 queries.  Two valid queries that are similar and the above
> query.
> "select * from Event where sourceId = protocolId"        //passes - because
> there is no stream name
> "select * from Event as E_A1 where E_A1.sourceId = E_A1.protocolId"      
> //FAILS
> "select * from Event.win:length(4) as E_A1 where E_A1.protocolId =
> E_A1.sourceId"        //passes - because there is a window defined

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



[jira] Issue Comment Edited: (ESPER-418) Statement fails to compile if the statement only has a where-clause and uses an alias

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


    [ http://jira.codehaus.org/browse/ESPER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197148#action_197148 ]

Thomas Bernhardt edited comment on ESPER-418 at 11/4/09 5:52 AM:
-----------------------------------------------------------------

Workaround is to remove the stream alias:
select * from ABC where sourceId = 3

It is confirmed that inspection/optimization of query execution causes this problem.

      was (Author: bernhardttom):
    Workaround is to remove the stream alias.
 

> Statement fails to compile if the statement only has a where-clause and uses an alias
> -------------------------------------------------------------------------------------
>
>                 Key: ESPER-418
>                 URL: http://jira.codehaus.org/browse/ESPER-418
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>            Reporter: Thomas Bernhardt
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>
> Hello
> I am using version 3.2.0 of Esper and have found what appears to be a bug in
> the way that the EPL is being compiled.
> I am using a very simple POJO as a test object with the following fields all
> with respective getter and setters.
> public class SimpleEvent
> {
>     private String uuid;
>     private Integer sourceId;
>     private Integer protocolId;
> }
> The following statement fails to register because it cannot find
> "A0.sourceId"
> select * from Event as A0 where A0.sourceId = 3
> The problem appears to be in the optimization that is done in
> StatementLifecycleSvcImpl.compile(...) at line 784.
> the comment is as follows
> // If not using a join and not specifying a data window, make the
> where-clause, if present, the filter of the stream
> What it is doing is if there are no joins and no windows defined it assumes
> that it can move the where clause up and use it as a filter.  It does this
> naively here
> 810:    FilterStreamSpecRaw streamSpec = (FilterStreamSpecRaw)
> spec.getStreamSpecs().get(0);
> 811:
> streamSpec.getRawFilterSpec().getFilterExpressions().add(whereClause);
> the problem is that by simple copying that up you end up with the following
> query.
> select * from Event( A0.sourceId = 3 ) as A0
> this optimization makes the statement invalid because it is trying to
> reference that A0 before it is defined.
> In order to be able to make that level of optimization it would have to
> check whether or not any of the properties in the where clause is referenced
> by an alias and then if it is either remove the reference to the alias or
> not make the optimization in that case.  However otherwise this prevents
> what should be a valid statement from being able to compile.
> I have included a simple test case that will show the problem.  it attempts
> to register 3 queries.  Two valid queries that are similar and the above
> query.
> "select * from Event where sourceId = protocolId"        //passes - because
> there is no stream name
> "select * from Event as E_A1 where E_A1.sourceId = E_A1.protocolId"      
> //FAILS
> "select * from Event.win:length(4) as E_A1 where E_A1.protocolId =
> E_A1.sourceId"        //passes - because there is a window defined

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



[jira] Resolved: (ESPER-418) Statement fails to compile if the statement only has a where-clause and uses an alias

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


     [ http://jira.codehaus.org/browse/ESPER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Bernhardt resolved ESPER-418.
------------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 4.0 - requires JDK6)
                   3.3

In release 3.3

> Statement fails to compile if the statement only has a where-clause and uses an alias
> -------------------------------------------------------------------------------------
>
>                 Key: ESPER-418
>                 URL: http://jira.codehaus.org/browse/ESPER-418
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>            Reporter: Thomas Bernhardt
>            Priority: Minor
>             Fix For: 3.3
>
>
> Hello
> I am using version 3.2.0 of Esper and have found what appears to be a bug in
> the way that the EPL is being compiled.
> I am using a very simple POJO as a test object with the following fields all
> with respective getter and setters.
> public class SimpleEvent
> {
>     private String uuid;
>     private Integer sourceId;
>     private Integer protocolId;
> }
> The following statement fails to register because it cannot find
> "A0.sourceId"
> select * from Event as A0 where A0.sourceId = 3
> The problem appears to be in the optimization that is done in
> StatementLifecycleSvcImpl.compile(...) at line 784.
> the comment is as follows
> // If not using a join and not specifying a data window, make the
> where-clause, if present, the filter of the stream
> What it is doing is if there are no joins and no windows defined it assumes
> that it can move the where clause up and use it as a filter.  It does this
> naively here
> 810:    FilterStreamSpecRaw streamSpec = (FilterStreamSpecRaw)
> spec.getStreamSpecs().get(0);
> 811:
> streamSpec.getRawFilterSpec().getFilterExpressions().add(whereClause);
> the problem is that by simple copying that up you end up with the following
> query.
> select * from Event( A0.sourceId = 3 ) as A0
> this optimization makes the statement invalid because it is trying to
> reference that A0 before it is defined.
> In order to be able to make that level of optimization it would have to
> check whether or not any of the properties in the where clause is referenced
> by an alias and then if it is either remove the reference to the alias or
> not make the optimization in that case.  However otherwise this prevents
> what should be a valid statement from being able to compile.
> I have included a simple test case that will show the problem.  it attempts
> to register 3 queries.  Two valid queries that are similar and the above
> query.
> "select * from Event where sourceId = protocolId"        //passes - because
> there is no stream name
> "select * from Event as E_A1 where E_A1.sourceId = E_A1.protocolId"      
> //FAILS
> "select * from Event.win:length(4) as E_A1 where E_A1.protocolId =
> E_A1.sourceId"        //passes - because there is a window defined

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email