Array of primitives: DynamicRealm support#5351
Array of primitives: DynamicRealm support#5351cmelchior merged 12 commits intocm/cm/primitivelist-schema-supportfrom
Conversation
…st-dynamicrealm # Conflicts: # realm/realm-library/src/main/java/io/realm/DynamicRealmObject.java
|
Ready for review @realm/java |
| } | ||
| final ManagedListOperator<?> operator = getOperator(proxyState.getRealm$realm(), osList, elementType, elementClass); | ||
|
|
||
| if (list.isManaged() && osList.size() == list.size()) { |
There was a problem hiding this comment.
When does this happen exactly? Is there a test for it? Is osList.size == list.size sufficient to determine that this is the case ❓
There was a problem hiding this comment.
No, but if the size() is different we know with 100% that the lists are not the same, in which case we can use clear() + insertAll() which is much faster than manually replacing each element in the the list.
If they are the same size() we don't know for sure, so we have to revert to manually replacing each element.
| /** | ||
| * Returns the {@link RealmList} of {@link DynamicRealmObject}s being linked from the given field. | ||
| * <p> | ||
| * If the list only contain primitive types, use {@link #getList(String, Class)} instead. |
| schema.setRequired("foo", false); | ||
| list = obj.getList("foo", byte[].class); | ||
| assertEquals(0, list.get(0).length); | ||
| assertArrayEquals(new byte[] {1, 2, 3}, list.get(1)); |
There was a problem hiding this comment.
Do you want to call
// Cleanup
schema.removeField("foo");
here as well?
It is actually no need, the tearDown will do that. So https://github.com/realm/realm-java/pull/5351/files#diff-4767794a7ded2dc2e3cc9447650ac1c7R838 can be removed as well.
| public <T> RealmList<T> getValueList(String fieldName, Class<T> valueClass) { | ||
| // TODO implement this | ||
| return null; | ||
| public <E> RealmList<E> getList(String fieldName, Class<E> elementType) { |
There was a problem hiding this comment.
I think #5329 (comment) applies here as well (that primitiveType is a better name)
There was a problem hiding this comment.
Why primitive is better? It's not a primitive type at least in Java.
There was a problem hiding this comment.
Technically because the feature is called "array of primitives".
The term element does not portray that this is not meant to be used for explicit RealmModel classes.
Originally I would have gone with the terminology "value list" but it wouldn't make sense for end users who don't read the commits 😮
There was a problem hiding this comment.
"array of primitives" is just a internal feature name and I don't think we are using it in our documentation /API.
There was a problem hiding this comment.
The problem is that no terminology is 100% correct without also being too vague:
elementType: Correct, but doesn't describe the difference between the RealmModel variant and this very well.
valueType: Date and byte[] isn't value types. Nor may others be in the future
primitiveType Date/byte[] isn't primitive types. Technically neither are any of the boxed types.
valueType is probably the one with the least amount of "wrongness", but IMO it is also a pretty specialized concept which I'm guessing not a lot know about. Primitive types is hopefylly someone even starting out with Java knows about.
Hence primitiveType
There was a problem hiding this comment.
We don't need to use the same word with core.
You don't need to, but I think the other alternatives allow for more confusion.
In fact, value type seems to mean something completely different...
There was a problem hiding this comment.
We don't need to use the same word with core.The most important thing is what is the most natural for Java developers.
True, but what is that? :)
There was a problem hiding this comment.
Especially, if there isn't a clear benefit_ to choosing another word, we should probably go with what is otherwise used in Core/Bindings/Issues.
There was a problem hiding this comment.
@cmelchior All candidates don't describe the difference between the RealmModel variant and expected ones well.
I could't find the reason to choose more incorrect one...
But I can accept your decision.
There was a problem hiding this comment.
I think it ended up staying elementType.
| break; | ||
| case LIST_INTEGER: | ||
| try { | ||
| dObj.setNull(NullTypes.FIELD_INTEGER_LIST_NULL); |
There was a problem hiding this comment.
why should this fail? FIELD_INTEGER_LIST_NULL is supporting null value
There was a problem hiding this comment.
Yes, but this is setting the field itself to null, not the values in the list. The field itself isn't allowed to be null.
Part of #5031
This PR adds support for primitive arrays in DynamicRealmObject
TODO
dynamicRealm.getList(), so I'm probably starting to lean towards having a seperateget<Primitive/Value>List()method instead ... People seem to like the overloaded methods best, so lets keep those.