Replies: 3 comments 1 reply
-
This is now checked in. |
Beta Was this translation helpful? Give feedback.
1 reply
-
I tried switching to the new |
Beta Was this translation helpful? Give feedback.
0 replies
-
Can you post details with a test case as an issue? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Enhanced Nested Property Support
The nested schema support in OneTable was added after the initial version was released. So the handling of nested properties on updates or finds is limited.
For example. I'd like to be able to do the following to find items with a matching nested property (after I define a nested schema).
It would be nice if this filtered those users with an address.zip == 12345. However, in the current version, this does not work. You need to use a where expression.
Similarly for updates. I'd like to be able to simply update address.zip in the user record.
However, in the current version, if the user already had an address with a street and city, those properties will be removed and the address will become: {zip: 12345}. So you need to use a {set: 'address.zip': 12345}. Again, not quite as elegant as we'd like.
Especially for update, this is not how top-level properties are handled. If top level properties are missing during an update, they are not set to null and not removed. If Table({nulls: false}) which is the default, setting a property to null will remove it. It would be nice if this behavior was possible for nested properties. i.e if the property is present, update it. If set to null, remove it. Otherwise, don't update and don't disturb peer properties at that level.
Nested Properties
This is a proposed solution to permit partial properties for use with find, remove, scan and update.
Table Params
A new "partial" table parameter controls how nested properties are handled. If set to true and nested schemas are defined for those properties, nested properties will be processed accordingly. At each level of the properties:
API Params
A new "partial" API parameter permits and API by API overriding of the "partial" behavior.
Backwards Compatibility
This change is backwards compatible if "partial" defaults to false.
However, I'd propose we should make "partial" default to true in the future. To be able to do this, I propose we issue a warning if "partial" is not set and ask all users to define "partial" to false or true. Then we can change the default for "partial" to true in the next major breaking change release.
Beta Was this translation helpful? Give feedback.
All reactions