-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data index incorrectly registered for date field to String #1441
Comments
@cristianonicolai @fjtirado need some help to figure why date field gets registered as string in graphql for data index... |
@debu999 I guess the register is well done to kogito.Date that is the expected, but It seems the type kogito.Date is not being found correctly. I'm taking a look here, trying to reproduce this. I'll let you know what I find. |
Sure. Seems to be something in proto which is not recognized in schema generation. |
@debu999, @Pradeepg21 Currently the dates included in process variables are added to the graphql schema as Strings. Even in the proto generation the proper marshaling are used to read and write Dates, it remains to add the fields as a Dates in the graphql schema. I've created https://issues.redhat.com/browse/KOGITO-7795 to add the Domain Dates fields mapping to graphql.DateTime instead or Strings.. |
Looking forward to the fix soon |
Hi @nmirasch , Do you have any update on this? |
@nmirasch any update on this. |
@nmirasch will there be anything in 1.28.0.Final on this?? |
@debu999 I'm sorry for the delay, as sooner this development will be included in 1.29. |
Hi @nmirasch, has this issue been fixed and getting push with release 1.29? Please keep us posted. |
@nmirasch is this still on target for 1.29 version |
hi @debu999, the dev is on this PR: https://github.com/kiegroup/kogito-apps/pull/1481 Still trying to merge it once the CI is green. I guess it will be for 1.30 release |
@nmirasch we tried using the date filters and seems it's implemented partially. For example in mongodb the data stored for a date field is till iso formated string where as metadata is stored as integer So only date filter works for kogtoeta data objects but not for variables with date Data type. Is there any change to be done in kogito runtime to store the date ans number instead. More over float or double is registered as string in graphql. |
@nmirasch For the following payload and businesskey datemongocheck1
I get the response for kogito runtime as
Lets look at the data in mongodb for instance from runtime
Data index version of data...
As you can see di query result
response:
now for some transformation breaks the same in during the query |
@nmirasch was there any findings on this and any advise on this discrepancy. |
@debu999 from the dataindex point of view, what we are doing is adding the received variables where dates come as a String into a graphql Date type. Now we can see those fields as Date at graphql, even before they were mapped as Strings, and AFAIK graphql date filters are supposed to work with that kind of fields. |
Is there a way to get the query fired to fetch data from mongodb. I did try with log level TRACE. But no query gets printed. To understand why it's not working might lie in the query being built to fetch data. |
@debu999 Usually we are using the DEBUG level to print the executed query, but reviewing the code I don't see that is included when executing query in mongodb. |
@nmirasch did we get any update on date filter issue for variables |
Do we need to look at mongodb storage project |
@debu999 We have added some logging to mongodb query execution to have more information about what's exactly the problem with that filtering (https://issues.redhat.com/browse/KOGITO-8292) |
@nmirasch
See the details. |
Any update on this @nmirasch |
Bug Details:
As per screenshot attached, we have created bbmn file for createdDate and UpdatedDate as type java.util.Date. Proto file correctly generated for both these field as Date type but in data index it got registered incorrectly with type as String.
Could anyone please check this urgently as it is blocking our development activity?
The text was updated successfully, but these errors were encountered: