namrathamyske closed issue #9659: Updating a property map in a iceberg table
URL: https://github.com/apache/iceberg/issues/9659
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
rdblue commented on issue #9659:
URL: https://github.com/apache/iceberg/issues/9659#issuecomment-1934991077
I don't think this is a good idea. We want to avoid keeping complex state in
table properties and use cases involving complex state in properties are often
not a good use of propertie
namrathamyske commented on issue #9659:
URL: https://github.com/apache/iceberg/issues/9659#issuecomment-1932693605
@amogh-jahagirdar it would be be simple for 1-2 keys, but can get complex if
number of keys increase
--
This is an automated message from the Apache Git Service.
To respond t
nastra commented on issue #9659:
URL: https://github.com/apache/iceberg/issues/9659#issuecomment-1928971630
One argument against having an API that supports setting/removing complex
non-string values is that Spark itself only supports string key/value pairs. I
believe the same is true for T
namrathamyske commented on issue #9659:
URL: https://github.com/apache/iceberg/issues/9659#issuecomment-1928560017
@amogh-jahagirdar There might be concurrency issues if we directly serialize
it to json string. Ex:
Current state of property-val key:
property-val : { "a1":1 }
amogh-jahagirdar commented on issue #9659:
URL: https://github.com/apache/iceberg/issues/9659#issuecomment-1928553290
IMO I'd prefer to keep the properties API in it's current simple state. To
handle the case where the value is a map, a user could always just serialize
the value into JSON
