Intents filtering

[vcuculo]

Could you please help me understand the semantic of startDate and endDate in intents filtering ? I cannot find documentation about it. Thank you!

Example:

query {
  intents(filter:{receiver:"01FJYNXAVNKXC931NCFAKE6JFB", startDate:"2021-10-30T10:00:00.000000Z"}, limit:50){
    id
  }
}

[densizengin]

Hi @vcuculo,

Currently the back-end ignores the fields (startDate and endDate), and I couldn't find any documentation about how to implement them either.

I had an idea about how to interpret the fields, but @adam-burns changed my mind about it. I asked about these to Lynn and Bob, and when they answer my questions, I'll let you know how should these work and I'll implement the specification. How does that sound to you?

Cheers, srfsh

[vcuculo]

Thank you @srfsh , mine was more a request for clarification on how to use those fields, in case they were used by the backend. I'm not sure that it is part of VF specifications. However, to implement a polling mechanism ti retrieve the list of intents, it would be very useful to be able to filter on DateTime fields with comparison logics (eg. =, <, >).

[densizengin]

[...] I'm not sure that it is part of VF specifications. However, to implement a polling mechanism ti retrieve the list of intents, it would be very useful to be able to filter on DateTime fields with comparison logics (eg. =, <, >).

Yeah, that's my point. I am not sure how to implement this. What I initially thought was that querying by startDate would query for either hasBeginning or hasPointInTime, and endDate would query for either hasEnd or due, but we talked about this with @adam-burns, and he convinced me that those mappings might not be right, and I decided to better ask this to Lynn and Bob. :)

[vcuculo]

I see, it could also be intended as the range (between startDate and endDate) of a specific DateTime field, rather than the start and end of the intent itself. Currently is possible to specify in the filter the value of hasBeginning, hasPointInTime etc., but is very limited since, I guess, it considers only == comparison.

[fosterlynn]

I have passed on the question to the people who have done the most work on the graphql spec, and will let you know when I hear back.

In the meantime, just a quick note to say if you want to filter intents by when they are published, like to display all active offers and needs, that would be up at Proposal, not at the Intent level. (Please ignore if not relevant.)

[pospi]

Hi all! There's a lot of room for input on these query edges- in terms of the GraphQL spec there aren't really any apps yet doing complex queries on records, so I would not be concerned about breaking compatibility in the process of altering / adding / removing parameters.

There has been some discussion surrounding the general nature of date-based queries at https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/83 which @fosterlynn and myself have tried to genericise a logic for, but the proposal and any PRs are very much open to input.

A spec (and indeed, a methodology) for making agent-relevant Intent and Commitment queries is also fertile ground, and something any use-case is welcome to contribute to https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/82

[densizengin]

Thanks a lot for the link, @pospi.

I think I get the idea about how it should be used. I've implemented a solution where I get the record that matches hasPointInTime >= startDate AND hasPointInTime < endDate or hasBeginning >= startDate AND hasEnd < endDate, and ignores due (because of how it is interpreted). So, basically this allows you to use the startDate field inclusively, endDate field exclusively. I think it fits your use-case pretty well, also a good solution in general. What do you think, @vcuculo?

[vcuculo]

Thanks @pospi and @srfsh , I think your proposed solution works good in most cases. How do you choose to handle the comparison against the pair hasBeginning-hasEnd rather than the value of hasPointInTime? Are these fields mutually exclusive?

[densizengin]

How do you choose to handle the comparison against the pair hasBeginning-hasEnd rather than the value of hasPointInTime? Are these fields mutually exclusive?

Yeah, that was my initial thought. I've also consulted this to Lynn a while ago, and she said that hasPointIntime can be mutually exclusive to hasBeginning and/or hasEnd. I guess that means one can have these combinations only (due is allowed in any combination also):

• only hasPointIntime
• only hasBeginning
• only hasEnd
• only hasBeginning and hasEnd

@fosterlynn what do you think? ^^

[fosterlynn]

I guess that means one can have these combinations only (due is allowed in any combination also):

That makes sense to me.

I've implemented a solution where I get the record that matches hasPointInTime >= startDate AND hasPointInTime < endDate or hasBeginning >= startDate AND hasEnd < endDate, and ignores due (because of how it is interpreted). So, basically this allows you to use the startDate field inclusively, endDate field exclusively.

One note: A lot of groups will not bother with time and just use date, depending on their needs.

I don't understand the use case for using endDate exclusively?

I feel like most of the use cases I'm familiar with for Intents are trying to find possible matches between offers and wants, so aren't very picky in general. If the query is to get any Intents that fall in that date range, you would need to also add OR (hasBeginning < startDate AND hasEnd > endDate).

I could be missing use cases that you are trying to address, of course!

[densizengin]

One note: A lot of groups will not bother with time and just use date, depending on their needs.

Not a problem, as far as I am concerned. Conversion from 2021-03-04 to 2021-03-04T00:00:00Z wouldn't be hard for an implementer. :D

I don't understand the use case for using endDate exclusively?

It is to allow rotating between startDate and endDate. Imagine that you want to loop through available Intents based on date (the case here). This allows an easier logic:

• first iteration: startDate = 2021-03-04, endDate = 2021-03-05
• second iteration: startDate = 2021-03-05, endDate = 2021-03-06
• third iteration: startDate = 2021-03-06, endDate = 2021-03-07
• and so on

If you look closely, all you do is use the old endDate and increase the new one by one, and it will give you all available Intents without any gap. It also works for generic use.

I feel like most of the use cases I'm familiar with for Intents are trying to find possible matches between offers and wants, so aren't very picky in general. If the query is to get any Intents that fall in that date range, you would need to also add OR (hasBeginning < startDate AND hasEnd > endDate).

I could be missing use cases that you are trying to address, of course!

Here, @vcuculo wanted to have a way to easily do pooling for the Intents. Though, I couldn't really understand why would I need this query. :D

[fosterlynn]

It is to allow rotating between startDate and endDate. Imagine that you want to loop through available Intents based on date (the case here). This allows an easier logic:

Ah I get it, that makes sense. Then I guess it depends on what use cases you all are thinking about. :)

[densizengin]

Alright then. I'll push the changes tomorrow. ^^

[densizengin]

Hey, @vcuculo. I've just published a new image. Can you test out the changes? ^^

[vcuculo]

Thank you @srfsh , I can confirm that the feature works as expected :wink: This issue can be closed.

[densizengin]

Thank you @srfsh , I can confirm that the feature works as expected wink This issue can be closed.

Cheers. ^^

I am also planning to document the usage of the fields when my colleague is available.

[vcuculo]

It would be great and useful!

[vcuculo]

As regards intents filtering, it would also be useful if the finished field is not ignored. Currently is provided in the filter, but it does not affect the query results. Let me know if a new issue is needed. Thank you!

[densizengin]

As regards intents filtering, it would also be useful if the finished field is not ignored. Currently is provided in the filter, but it does not affect the query results. Let me know if a new issue is needed. Thank you!

Thanks for reporting! I am on it. ^^

[densizengin]

As regards intents filtering, it would also be useful if the finished field is not ignored. Currently is provided in the filter, but it does not affect the query results. Let me know if a new issue is needed. Thank you!

I just released another image fixing this. Can you try it out? Thank you! ^^

[vcuculo]

Wow, so fast! Thank you, just tested and it works as expected!