I am experimenting with Nesper (.NET version of Esper) and ran into a few troubles that I just cannot understand. The following simple EPL (modeled after the tutorial) fails with an error:
select * from pattern [every (e1=SeenEvent -> e2=SeenEvent(ID=e1.ID))
where timer:within(1 min)]
The error I get is:
Property named 'ID' is not valid in any stream
My first suspect was the ID may not be exposed correctly in the SeenEvent class which derives from Observation class. But I confirmed that in Observation class property ID is defined as Public.
Is this a known issue with EPL? Is Nesper different from Esper (it's Java cousin)?
You could try "select ID from SeenEvent" to confirm whether "ID" is actually exposed. The property names are case-sensitive, try "id" as well. Rename the property may also help.
Related
I am getting undefined, when using agent.parameters.geo-country while using the System entity #Sys.geo-country.
This is the error I am getting.
https://drive.google.com/file/d/1-rP9rkvOB3Wm0KyGn846iFbMBFb2Iu9c/view?usp=drivesdk
JSON property syntax (x.y.z) doesn't like the dash. In order to get around that, you can use the alternative bracket syntax (x['y']['z'])
In your case, you could use agent.parameter['geo-country'].
Another thing you can do instead is look at the name of the paramter, and change it if you want.
For example, in the case below, the entity type is #sys.any, but I've named it to search. This means I could instead use agent.parameter.search which may be more useful to me.
If I’m looking at a Record pulled from a StatementResult, what is the right way to determine the type of a particular value? I know Neo will try to coerce types for me but what if I want to know, for example, if something is a Node? There is a typeOf() method that you can call but I don’t see where I get the Value to pass to that method. For example in the following snippet how do I determine the type of the value held by key?
StatementResult statementResult = session.run(cypher,paramMap);
Record record = single();
record.get('key').type().isTypeOf()
How about:
boolean isNumber = record.get("key").type().equals(session.typeSystem().NUMBER());
See https://github.com/neo4j/neo4j-java-driver/blob/1.0/driver/src/main/java/org/neo4j/driver/v1/types/TypeSystem.java for details.
I think Stefan's answer is perfectly valid, however it will bound your code to the v1 of the protocol.
I would use the internal namespace in order to keep it working in further versions, for eg :
import static org.neo4j.driver.internal.types.InternalTypeSystem.TYPE_SYSTEM;
if ( record.get( "key" ).hasType( TYPE_SYSTEM.NODE() ) {
// it is a node
}
From what I can see in the driver test, it is the same usage :
https://github.com/neo4j/neo4j-java-driver/blob/1.1/driver/src/test/java/org/neo4j/driver/v1/types/TypeSystemTest.java#L210
I found a very strange behavior in our grails application today that i want to share with you.
We are using grails 2.3.11 on mysql 5.1.48.
We had a DomainObject.findById( id ) in one of your Controller actions.
We failed to check the id for a null value so DomainObject.findById( null )
would be called when no id is passed as an argument.
Normally DomainObject.findById( null )
will return null but there is a special condition that will yield other results!
If the controller action called before that inserted a new record in the database (lets call it Object B), regardless of the domain object stored, the DomainObject.findById( null ) will find the DomainObject with the same Id the Object B got on insert.
So when the controller action called before saved anything the findById(null) will return a row. And that row will have the same id the last inserted element got.
I am totally aware that using findById(null) is not the desired way to do it but I was quite shocked about the results it yielded. But returning any seemingly "random" result seems very strange to me.
I also want to note that DomainObject.get(null) will not suffer from this problem.
Anybody else witnessed this?
There is an active Jira pointing in this direction: https://jira.grails.org/browse/GRAILS-9628 but its not really describing this issue.
We don't really support passing null as an argument to a dynamic finder like that. Dynamic finders have explicit support for querying by null. Instead of DomainClass.findByName(null) you would call DomainClass.findByNameIsNull(). If you have a reference that may or may not be null, instead of passing that as an argument to a dynamic finder, the code can almost always be made cleaner by writing a criteria query or a "where" query that has a conditional in it.
I hope that helps.
Thx for your information scot.
I have further details. This behaviour is also altered by the underlying database.
While mysql suffers from this, maria-db (a mysql clone) does not!
So what happens is bound to the underlying database system.
That should not happen to an abstraction layer ....
I apologize if I'm missing something really obvious here but I've been pulling my hair out with this issue.
I have a command object:
class MyCommand {
Long id
String value
}
I bind to this in my controller:
public update(MyCommand myCmd) {
}
Everything is fine in this scenario. Now I'm trying to add the version field, which is passed in the request parameters to the command object:
class MyCommand {
Long id
Long version
String value
}
Now however when the binding happens the id and version are always null, even though they are present in the params object.
I suspected that there may be some special handling for id / version attributes related to how grails handles optimistic locking (as this is ultimately why I'm doing this) but the issue is present at the command object independent of any domain object.
I'm baffled why this is not working. Is there some special case when version is present on a command object?
Seems this is by design per Jeff Brown jira
The data binding explicitly avoids binding id or version [if] they both
exist and does this by design. This is a shield against potential
security problems relevant to data binding as it relates to domain
classes. A simple work around for command objects would be to name the
properties with something like "idValue" and "versionValue" or
anything other than "id" and "version".
Hello I am trying to execute a query using breezejs 1.3.4 . My query is the following
function getContacts() {
var query = breeze.EntityQuery
.from("Contacts").where("Desc", "startsWith", "P");
return manager.executeQuery(query)
.then(getSucceeded).fail(getFailed);
}
"Desc" is a string property in my "Contacts" C# backend model. Tha problem is that the Query URL is formatted like this .../api/Application/Contacts?$filter=startswith(Desc%2Ctime'P')%20eq%20true
The word time is added before "P" and I get a this exception in the Response
{"$id":"1","$type":"System.Web.Http.HttpError, System.Web.Http","Message":"The query specified in the URI is not valid.","ExceptionMessage":"Unrecognized 'Edm.Time' literal 'time'P''
If in the comparison I use a lower case "p" then the Url is costructed as it should be like this
"$filter=startswith(Desc%2C'p')%20eq%20true` .
I don't have the same problem when using other UpperCase letters of the english alphabet.
Does anyone have an idea what am I missing, I can't figure out why the word "time" is added in that specific query?
Thank you.
We were able to reproduce the problem.
While the exception message is confusing, I believe you might be getting the error because you have not associated that the resource name 'Contacts' with an EntityType of presumably 'Contact'.
What is happening is that when Breeze tries to build the query it will usually use its metadata to correctly format the url query string to send to the server. The critical part of this process involves determining the EntityType associated with the resourceName given in the 'from' clause of the query ('Contacts' in your case). Breeze uses a resource name to entity type map to do this, but if it cannot find a mapping, it will still continue to build the url because we still need to support ad-hoc requests against endpoints for which we have no metadata.
You can update this map yourself via the MetadataStore.setEntityTypeForResourceName method. If you are using the Entity Framework, this map is initially populated based on the EntityType name/Entity Set name mapping that is part of your EDMX model. So in your case you can either modify your EDMX model or call the setEntityTypeForResourceName method directly.
Unfortunately, without the metadata Breeze has to infer the datatypes in the query. So in your case
"Desc", "startsWith", "P"
since Breeze can't determine that "Desc" is a 'string' property of your Contract EntityType it tries to infer the 'dataType' of "Desc" based on the value 'P'. Unfortunately, 'P' is a valid ISO8601 'duration' value ( a way to express a 'Time' datatype), so Breeze incorrectly tries to construct a query string with 'P' treated as a 'Time' constant. This is why your code works with a lower case 'p' ( not a valid duration value).
This inference logic can certainly be improved and we have a fix that will allow us to do exactly that coming out in the next release. However... the better and more general solution to this type of issue is to get the 'resourceName/entityType' mappings correct in the first place.
Hope this helps.