You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now filtering on primary and foreign keys work with the actual values from the database. This leaks an implementation detail and might be cumbersome to deal with if the datatype of this identifier changes in the future (for example from integer to uuid). If primary and foreign keys could be filtered by nodeId, this problem would be solved. Furthermore it would provide consistency with other methods that accept nodeId's.
The text was updated successfully, but these errors were encountered:
Could you expand on how you would want to filter on nodeId? Anything beyond equalTo/notEqualTo/in/notIn? I'm thinking anything outside of those wouldn't make sense for what's supposed to be an opaque identifier.
Right now filtering on primary and foreign keys work with the actual values from the database. This leaks an implementation detail and might be cumbersome to deal with if the datatype of this identifier changes in the future (for example from integer to uuid). If primary and foreign keys could be filtered by nodeId, this problem would be solved. Furthermore it would provide consistency with other methods that accept nodeId's.
The text was updated successfully, but these errors were encountered: