Skip to content

Allow passing POJOs as field values throughout API. #76

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

Merged
merged 9 commits into from
Oct 23, 2018

Conversation

mikelehen
Copy link
Contributor

All of our parsing code now accepts POJOs meaning you can pass them:

  • As values in a Map<> passed to set().
  • As values to a update() call.
  • As elements in an array transform operation.
  • As values in query field filters.

Also removed set(Map<>) overloads since they are now redundant with set(Object).

All of our parsing code now accepts POJOs meaning you can pass them:
* As values in a Map<> passed to set().
* As values to a update() call.
* As elements in an array transform operation.
* As values in query field filters.

Also removed set(Map<>) overloads since they are now redundant with set(Object).
Copy link
Contributor Author

@mikelehen mikelehen left a comment

Choose a reason for hiding this comment

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

FYI-

  1. This feature comes with a code savings of 78 lines!
  2. This hasn't finished going through API review so no rush on the review (you can hold off if you want).

reason = "Could not serialize object. " + reason;
if (path.getLength() > 0) {
reason = reason + " (found in field '" + path.toString() + "')";
}
return new RuntimeException(reason);
return new IllegalArgumentException(reason);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some errors (in particular trying to use an Array instead of a List) are now getting caught in the POJO mapper instead of our UserDataConverter. To keep the exception type consistent, I CustomClassMapper to throw IllegalArgumentExceptions (which is more correct anyway).

@@ -411,7 +411,7 @@ public void testArraysFail() {
wrap(array);
fail("wrap should have failed");
} catch (IllegalArgumentException e) {
assertNotEquals(-1, e.getMessage().indexOf("use a List instead"));
assertNotEquals(-1, e.getMessage().indexOf("use Lists instead"));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This error is now coming from CustomClassMapper and so the wording changed slightly.

Copy link
Contributor

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

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

LGTM. I left one optional suggestion that can help you make this PR longer (impact!).

// Convert POJOs
Object converted = CustomClassMapper.convertToPlainJavaTypes(input);

if (source == UserData.Source.Set && !(converted instanceof Map)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

How excited do you feel about moving this assert (and maybe the if-check in 203) to parseMergeData and parseSetData?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made a convertAndParseDocumentData() helper instead. Does that work? This added 3 lines, but I found some test comments to fix up which ended up removing 7 lines, so we're okay.

@mikelehen
Copy link
Contributor Author

/retest

@ashwinraghav
Copy link
Contributor

/test smoke-tests-debug

@allisonbm92
Copy link
Contributor

/test smoke-tests-debug
/test smoke-tests-release

@mikelehen
Copy link
Contributor Author

/test smoke-tests-debug

@ashwinraghav
Copy link
Contributor

/retest

Michael Lehenbauer and others added 2 commits October 22, 2018 11:45
* Added `T get(..., Class<T>, ...)` overloads for extracting fields as a custom
  class (POJO) type.
@mikelehen
Copy link
Contributor Author

/retest

@mikelehen
Copy link
Contributor Author

/test connected-check

@mikelehen mikelehen merged commit ddda926 into master Oct 23, 2018
@mikelehen mikelehen deleted the mikelehen/pojo-field-writes branch October 23, 2018 00:37
wilhuff added a commit that referenced this pull request Jan 11, 2019
wilhuff added a commit that referenced this pull request Jan 12, 2019
@firebase firebase locked and limited conversation to collaborators Oct 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants