Skip to content

Array of primitives: DynamicRealm support#5351

Merged
cmelchior merged 12 commits intocm/cm/primitivelist-schema-supportfrom
cm/primitivelist-dynamicrealm
Oct 3, 2017
Merged

Array of primitives: DynamicRealm support#5351
cmelchior merged 12 commits intocm/cm/primitivelist-schema-supportfrom
cm/primitivelist-dynamicrealm

Conversation

@cmelchior
Copy link
Copy Markdown
Contributor

@cmelchior cmelchior commented Sep 29, 2017

Part of #5031
This PR adds support for primitive arrays in DynamicRealmObject

TODO

  • Cleanup
  • Fix RealmSchema unit tests so they use DynamicRealm instead
  • Determine naming. See Array of Primitives: RealmObjectSchema support #5329 . I already made several mistakes with the overloaded dynamicRealm.getList(), so I'm probably starting to lean towards having a seperate get<Primitive/Value>List() method instead ... People seem to like the overloaded methods best, so lets keep those.

@cmelchior
Copy link
Copy Markdown
Contributor Author

Ready for review @realm/java

}
final ManagedListOperator<?> operator = getOperator(proxyState.getRealm$realm(), osList, elementType, elementClass);

if (list.isManaged() && osList.size() == list.size()) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When does this happen exactly? Is there a test for it? Is osList.size == list.size sufficient to determine that this is the case ❓

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

contain -> contains

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));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think #5329 (comment) applies here as well (that primitiveType is a better name)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why primitive is better? It's not a primitive type at least in Java.

Copy link
Copy Markdown
Contributor

@Zhuinden Zhuinden Oct 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😮

Copy link
Copy Markdown
Contributor

@zaki50 zaki50 Oct 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"array of primitives" is just a internal feature name and I don't think we are using it in our documentation /API.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

@Zhuinden Zhuinden Oct 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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? :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it ended up staying elementType.

Copy link
Copy Markdown
Collaborator

@nhachicha nhachicha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small comment

break;
case LIST_INTEGER:
try {
dObj.setNull(NullTypes.FIELD_INTEGER_LIST_NULL);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why should this fail? FIELD_INTEGER_LIST_NULL is supporting null value

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@cmelchior cmelchior merged commit 3fa8e2e into cm/cm/primitivelist-schema-support Oct 3, 2017
@cmelchior cmelchior deleted the cm/primitivelist-dynamicrealm branch October 3, 2017 08:49
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants