-
Notifications
You must be signed in to change notification settings - Fork 66
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
older style structured properties issue #129
Comments
Looking at this. Thanks. |
Hi @alexrwix , I'm trying to understand how or why this would come up. In an interactive console, I've used the py27 version of NDB to create and store an entity:
The entity it creates in Datastore is:
As you can see, missing values for subproperties are filled in with
That would get interpreted as having a single subentity where Hewing more closely to your example:
We get:
Because the nulls are included, this should work just fine with the code as-is. Consider this variant:
Which gets us:
Here, if we were to elide the nulls such that Is there a real-world use case I'm missing where NDB would be writing the subentities without |
Hi Chris. Our repeated structured property models inherited from ndb.Expando so the same models sometimes have a different set of properties. Below is an example of real datastore entity output property is:
Here is an entitiy example loaded directly from datastore:
After loading with py37 python-ndb, output items array has 8 items instead of with 12 But the biggest problem is that this issue is INCONSISTENT! In case of this properties order, all items loaded correctly
|
So, I've tweaked my py2.7 test script to use
Doing this, I do get an entity with uneven repeated property lengths, like you describe:
The part that I'm still having trouble with is the fact that the subentities, in effect, are getting scrambled. If we just naively pad the end of the shorter property with nulls, we'll get the following subentities:
This, obviously, isn't what we tried to store and as far as I can tell is a bug, not a feature to be replicated. Unless I am missing something, the sub-entities in your production database are going to be somewhat mixed up with properties that were saved as being part of one sub-entity, being assigned to a different sub-entity upon retrieval. Do you see what the problem is here? Is there something I'm missing? |
Hi Chris. I have never tried such scenario. What is your suggestion? |
Correct.
As far as I can tell, your example is such a scenario.
In your example,
That is a good question. I don't know yet. We probably need to have some internal discussion. I believe I understand the problem, but want to discuss with my team what the best approach for a solution might be. |
Thank you. |
Legacy NDB had a bug where, with repeated Expando properties, it could end up writing arrays of different length if some entities had missing values for certain subproperties. When Cloud NDB read this out, it might have only loaded entities corresponding to the shorter array length. See issue googleapis#129 . To fix this, with PR googleapis#176 , we made Cloud NDB check if there are length differences and pad out the array as necessary. However, depending on the order properties are returned from Datastore in, we may have accidentally padded with subentities of the wrong kind, because it was possible to skip over updating the kind if we alternated between updating repeated properties. (Eg: A.a with 2 elements, B.b with 3 elements, A.c with 3 elements -> A would end up with an element of B's kind)
Legacy NDB had a bug where, with repeated Expando properties, it could end up writing arrays of different length if some entities had missing values for certain subproperties. When Cloud NDB read this out, it might have only loaded entities corresponding to the shorter array length. See issue googleapis#129 . To fix this, with PR googleapis#176 , we made Cloud NDB check if there are length differences and pad out the array as necessary. However, depending on the order properties are returned from Datastore in, we may have accidentally padded with subentities of the wrong kind, because it was possible to skip over updating the kind if we alternated between updating repeated properties. (Eg: A.a with 2 elements, B.b with 3 elements, A.c with 3 elements -> A would end up with an element of B's kind)
… ds (#824) Legacy NDB had a bug where, with repeated Expando properties, it could end up writing arrays of different length if some entities had missing values for certain subproperties. When Cloud NDB read this out, it might have only loaded entities corresponding to the shorter array length. See issue #129 . To fix this, with PR #176 , we made Cloud NDB check if there are length differences and pad out the array as necessary. However, depending on the order properties are returned from Datastore in, we may have accidentally padded with subentities of the wrong kind, because it was possible to skip over updating the kind if we alternated between updating repeated properties. (Eg: A.a with 2 elements, B.b with 3 elements, A.c with 3 elements -> A would end up with an element of B's kind)
There is an additional issue with py27 ndb models with dotted property names.
Related to #126
In the case of a structured property which has repeated properties of different lengths, only the first two items are loaded.
For example:
Current result (py37 python-ndb):
TestRepeatedStructuredModel(key=Key('TestRepeatedStructuredModel', '123456'), int_prop=42, struct_prop=StructuredRepeatedPropModel(key=Key('StructuredRepeatedPropModel', None), items=[StructuredPropModel(key=Key('StructuredPropModel', None), one='first', three='third', two='second'), StructuredPropModel(key=Key('StructuredPropModel', None), one='first-1', three='third-1', two='second-1')]))
Expected result (py27 ndb):
TestRepeatedStructuredModel(key=Key('TestRepeatedStructuredModel', '123456'), int_prop=42, struct_prop=StructuredRepeatedPropModel(key=Key('StructuredRepeatedPropModel', None), items=[StructuredPropModel(key=Key('StructuredPropModel', None), one='first', three='third', two='second'), StructuredPropModel(key=Key('StructuredPropModel', None), one='first-1', three='third-1', two='second-1'), StructuredPropModel(key=Key('StructuredPropModel', None), one=None, three='third-2', two=None)]))
All working as expected, if all dotted repeated properties have the same length
Entity Protobuf:
Test example:
The text was updated successfully, but these errors were encountered: