removing a named window

[morgandev]

Is there a way to remove or detroy a named window?  I've tried both
destroy() on the EPStatement that created the window, and destroy() on
EPServiceProvider with no success.  When destroy and reinit I then get
an error that the window has already exists.

com.espertech.esper.client.EPStatementException: Error starting view:
A named window by name 'SomeName' has already been created

thanks

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

    http://xircles.codehaus.org/manage_email

[Thomas Bernhardt]

Some parts of this message have been removed. Learn more about Nabble's security policy.

The destroy() on the EPStatement that created the named window does remove the named window. However the implicit event type stays since further statements may continue to use that type. Therefore the named window can be created again as long as the type information matches the prior declaration for the named window.

Best regards,
Tom

----- Original Message ----
From: Scott Morgan <morgandev@...>
To: user@...
Sent: Thursday, September 18, 2008 8:39:54 PM
Subject: [esper-user] removing a named window

Is there a way to remove or detroy a named window?  I've tried both
destroy() on the EPStatement that created the window, and destroy() on
EPServiceProvider with no success.  When destroy and reinit I then get
an error that the window has already exists.

com.espertech.esper.client.EPStatementException: Error starting view:
A named window by name 'SomeName' has already been created

thanks

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

    http://xircles.codehaus.org/manage_email

[MitchH]

I think this is a problem. The same happens with insert statements, an implicit event type is created which cannot be removed even when there are no further references to it in any of the compiled statements. I just posted this as a bug in JIRA but maybe it is a documentation/feature issue. It ought to be possible to substitute a statement the running engine without having to write code to track the rules' dependencies and doing renaming in the replacement statement. Or am I missing something?

Thomas Bernhardt wrote:

The destroy() on the EPStatement that created the named window does remove the named window. However the implicit event type stays since further statements may continue to use that type. Therefore the named window can be created again as long as the type information matches the prior declaration for the named window.

Best regards,
Tom

----- Original Message ----
From: Scott Morgan <[e-mail]>
To: [e-mail]
Sent: Thursday, September 18, 2008 8:39:54 PM
Subject: [esper-user] removing a named window

Is there a way to remove or detroy a named window?  I've tried both
destroy() on the EPStatement that created the window, and destroy() on
EPServiceProvider with no success.  When destroy and reinit I then get
an error that the window has already exists.

com.espertech.esper.client.EPStatementException: Error starting view:
A named window by name 'SomeName' has already been created

thanks

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

    http://xircles.codehaus.org/manage_email


     

[Thomas Bernhardt]

Some parts of this message have been removed. Learn more about Nabble's security policy.

There is operations in ConfigurationOperations accessible from the admin interface to remove types.
-Tom

---

From: MitchH <m2@...>
To: user@...
Sent: Tuesday, September 8, 2009 6:00:52 AM
Subject: [esper-user] Re: re[esper-user] moving a named window


I think this is a problem. The same happens with insert statements, an
implicit event type is created which cannot be removed even when there are
no further references to it in any of the compiled statements. I just posted
this as a bug in JIRA but maybe it is a documentation/feature issue. It
ought to be possible to substitute a statement the running engine without
having to write code to track the rules' dependencies and doing renaming in
the replacement statement. Or am I missing something?


Thomas Bernhardt wrote:

>
> The destroy() on the EPStatement that created the named window does remove
> the named window. However the implicit event type stays since further
> statements may continue to use that type. Therefore the named window can
> be created again as long as the type information matches the prior
> declaration for the named window.
>
> Best regards,
> Tom
>
> ----- Original Message ----
> From: Scott Morgan <morgandev@...>
> To: user@...
> Sent: Thursday, September 18, 2008 8:39:54 PM
> Subject: [esper-user] removing a named window
>
> Is there a way to remove or detroy a named window?  I've tried both
> destroy() on the EPStatement that created the window, and destroy() on
> EPServiceProvider with no success.  When destroy and reinit I then get
> an error that the window has already exists.
>
> com.espertech.esper.client.EPStatementException: Error starting view:
> A named window by name 'SomeName' has already been created
>
> thanks
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>

>    http://xircles.codehaus.org/manage_email
>
>
>     
>

--
View this message in context: http://www.nabble.com/removing-a-named-window-tp19564288p25343144.html
Sent from the Esper User list mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email

[MitchH]

OK thanks. I still don't see how to establish a statement's dependencies so that if the epl is changed, we know what to recompile. You can discover what statements are referenced by an event type but not vice versa. My use case is where there is a live engine working on real time data and a test engine working on historical data for statement development.

Given some arbitrary changes to the test epl, is it possible to work out which of the live statements to recompile or does the application have to track the dependencies?

Thomas Bernhardt wrote:

There is operations in ConfigurationOperations accessible from the admin interface to remove types.
-Tom


________________________________
From: MitchH <[e-mail]>
To: [e-mail]
Sent: Tuesday, September 8, 2009 6:00:52 AM
Subject: [esper-user] Re: re[esper-user] moving a named window


I think this is a problem. The same happens with insert statements, an
implicit event type is created which cannot be removed even when there are
no further references to it in any of the compiled statements. I just posted
this as a bug in JIRA but maybe it is a documentation/feature issue. It
ought to be possible to substitute a statement the running engine without
having to write code to track the rules' dependencies and doing renaming in
the replacement statement. Or am I missing something?

[Thomas Bernhardt]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Mitch,
to find for each event type the referred-by statements, the logic is
((EPServiceProviderSPI) engine.)getStatementEventTypeRef().getStatementNamesForType(eventType.getName());
The SPI interface is subject to change between versions.
Application-provided annotations could be the easiest way to go, or statement user object.
Best regards,
Tom

---

From: MitchH <m2@...>
To: user@...
Sent: Wednesday, September 9, 2009 9:27:58 AM
Subject: [esper-user] Re: Re: re[esper-user] moving a named window


OK thanks. I still don't see how to establish a statement's dependencies so
that if the epl is changed, we know what to recompile. You can discover what
statements are referenced by an event type but not vice versa. My use case
is where there is a live engine working on real time data and a test engine
working on historical data for statement development.

Given some arbitrary changes to the test epl, is it possible to work out
which of the live statements to recompile or does the application have to
track the dependencies?


Thomas Bernhardt wrote:

>
> There is operations in ConfigurationOperations accessible from the admin
> interface to remove types.
> -Tom
>
>
> ________________________________
> From: MitchH <m2@...>
> To: user@...
> Sent: Tuesday, September 8, 2009 6:00:52 AM
> Subject: [esper-user] Re: re[esper-user] moving a named window
>
>
> I think this is a problem. The same happens with insert statements, an
> implicit event type is created which cannot be removed even when there are
> no further references to it in any of the compiled statements. I just
> posted
> this as a bug in JIRA but maybe it is a documentation/feature issue. It
> ought to be possible to substitute a statement the running engine without
> having to write code to track the rules' dependencies and doing renaming
> in
> the replacement statement. Or am I missing something?
>
>
>

--
View this message in context: http://www.nabble.com/removing-a-named-window-tp19564288p25365017.html
Sent from the Esper User list mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email

[MitchH]

Thanks, Tom- I'll have a play.

Thomas Bernhardt wrote:

Hi Mitch,
to find for each event type the referred-by statements, the logic is
((EPServiceProviderSPI) engine.)getStatementEventTypeRef().getStatementNamesForType(eventType.getName());
The SPI interface is subject to change between versions.
Application-provided annotations could be the easiest way to go, or statement user object.
Best regards,
Tom




________________________________
From: MitchH <[e-mail]>
To: [e-mail]
Sent: Wednesday, September 9, 2009 9:27:58 AM
Subject: [esper-user] Re: Re: re[esper-user] moving a named window


OK thanks. I still don't see how to establish a statement's dependencies so
that if the epl is changed, we know what to recompile. You can discover what
statements are referenced by an event type but not vice versa. My use case
is where there is a live engine working on real time data and a test engine
working on historical data for statement development.

Given some arbitrary changes to the test epl, is it possible to work out
which of the live statements to recompile or does the application have to
track the dependencies?


Thomas Bernhardt wrote:
>
> There is operations in ConfigurationOperations accessible from the admin
> interface to remove types.
> -Tom
>
>
> ________________________________
> From: MitchH <[e-mail]>
> To: [e-mail]
> Sent: Tuesday, September 8, 2009 6:00:52 AM
> Subject: [esper-user] Re: re[esper-user] moving a named window
>
>
> I think this is a problem. The same happens with insert statements, an
> implicit event type is created which cannot be removed even when there are
> no further references to it in any of the compiled statements. I just
> posted
> this as a bug in JIRA but maybe it is a documentation/feature issue. It
> ought to be possible to substitute a statement the running engine without
> having to write code to track the rules' dependencies and doing renaming
> in
> the replacement statement. Or am I missing something?
>
>
>

--
View this message in context: http://www.nabble.com/removing-a-named-window-tp19564288p25365017.html
Sent from the Esper User list mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email