REST query returns no results when it should return some

[l-1]

StructrScript function filter() works perfect and returns needed results, but REST returns no results when querying on computer properties (Function or Count).
For example:
projectCount (Function): size(this.projects)
projects (Function): merge_unique(this.projectsRedundant)
projects (Notion): skillRequests, projectProperty (projectPropertyin remote attribute is another Notion property.)
hasProjects (Function): gt(this.projectCount,0)

REST query returns no results when querying on ?projectCount=1 or ?hasProjects=true, although querying without those parameters one can see in response that there are records with

"hasProjects": true
"projectCount": 1

And as I mentioned in the beginning of this issue, StructrScript function filter() works perfect and returns needed results.

[eric-schleicher]

I've seen this too when data is not found based on the direction of the
relationship, it's possible that filter is traversing differently. As an
experiment, can you run re-index (the topmost button in #Schema-> Admin
Tools) and immediately try again? while not the exact same scenario, I'm
curious if it's the same underlying issue as this one:
#446

[l-1]

Re-indexing helped, thanks! But isn't it more like a bug? One must always re-index after adding computed properties to be able to use them in queries?

Here's my directions

[eric-schleicher]

I would tend to agree. As an oltp type system, we should not see this
type of query inconsistency .

Im not sure if the issue has been classified yet. In my applications its
an annoyance, not yet critical.

Eric

On Aug 28, 2016 4:37 AM, "Leo" notifications@github.com wrote:

Re-indexing helped, thanks! But isn't it more like a bug? One must always
re-index after adding computed properties to be able to use them in
queries?

Here's my directions
[image: skill-projectproperty]
https://cloud.githubusercontent.com/assets/17904494/18033371/38087cd6-6d2b-11e6-8811-7fe75c26e344.png

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#469 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH4Qly3R1ouh5g3U0XZUHNyae5r6-w23ks5qkXLbgaJpZM4Jt-0x
.

[cmorgner]

The problem here is that the result of a FunctionProperty is of unknown type. projectCount is an integer value, hasProjects is a boolean value, but both are the result of the same (untyped) FunctionProperty, so Structr does not know how to convert the (string-based) request parameter value to the desired type (which is necessary to get the correct query results).

There are two options to solve this problem:

1. convert and treat all FunctionProperty results as a string
2. introduce typed function properties, i.e. IntFunctionProperty, BooleanFunctionProperty etc.

Both approaches have advantages and disadvantages; right now, I'd prefer typed function properties, but I'd like to discuss that with the team.

[l-1]

Hi @cmorgner,

I see that a Function Property now being typed, but the problem still persists.

Is there any update on this issue?

[cmorgner]

Yes, you can give a function property a type hint now (string, integer, double, boolean etc., lower case), which should solve the typing problem. This has in fact become one of the things that need to be done in order to filter REST results with a function property.

Another thing that came to my mind while reading the previous comments: re-indexing is only necessary when you add an indexed function property to existing data. For new objects, the indexed property should be handled correctly.

Which version are you using? I am reasonably sure that REST queries on an indexed typed function property work correctly for quite some time now.

Can you share the part of your data model and the corresponding query that doesn't work?

[l-1]

Sorry for not mentioning it earlier, I'm using 3.5-SNAPSHOT, which I built myself.

I've got a strange behavior on this one: it's working using StructrScript both on Pages and in concolse. Also it's working in console in REST mode, but the same (copy-pasted) query doesn't work in actual REST query.

I've got Customer-[1:*]->Contact.
Contact has contact_type and value properties, both strings.
Customer has phone function property with type hint String. Read script of that property is:

filter(this.contacts,equal(data.contact_type,'phone'))[0].value

Query's like /Customer?phone=+18001234567.

Btw, what's your preferred way to model or to read these kind of things? Like subtyping on schema level and using particular relationships for each kind of contacts?

[cmorgner]

Just off the top of my head, the plus sign in the query string could have something to do with the problem, i.e. URL encoding (?).

[cmorgner]

The preferred way depends very much on the different use cases for the data. The easiest (but least flexible) would be to store the most important info on the Customer node to make it easily queryable.

Your approach is also quite good and much more flexible, but has the downside of having to use a lot of function properties.

You could also use a custom result page for your own facetted search (which we have done many times in the past) to bypass the limitations of REST / query URLs.

It's not easy to give good advice with little information. :)