Skip to content
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

feast serve convert number to INT64 #4110

Closed
Akshay-deqode opened this issue Apr 17, 2024 · 1 comment · Fixed by #4117
Closed

feast serve convert number to INT64 #4110

Akshay-deqode opened this issue Apr 17, 2024 · 1 comment · Fixed by #4117

Comments

@Akshay-deqode
Copy link

Expected Behavior

when we use the get-online-features endpoint the request body numbers converted to Int64 type and while from python file calling get_online_feature function convert number to Int32 which leads to inconsistency between both use
if the entity value type is Int32 then feature servering with online feast serve command will not work expected behavior is to convert the value to Int32 while it is being converted to Int64

Current Behavior

when using feast serve number are converted to Int64 type

Steps to reproduce

create a entity with a column with type Int32 create a feature view with the entity apply the changes using feast apply materialize the data to online store start feature server using feast serve and call endpoint /get-online-feature to retrive feature ... expected response is the feature retrived while it show none due to type issue

Specifications

  • Version: 0.36
  • Platform:
  • Subsystem:

Possible Solution

before converting the type to Int64 get the repo and convert the type to the entity data type defined
other solution is just write in doc to use Int64 and Float64 type while defining entity

@tokoko
Copy link
Collaborator

tokoko commented Apr 19, 2024

@Akshay-deqode thanks for filing the issue, I was able to reproduce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants