-
Notifications
You must be signed in to change notification settings - Fork 123
centralize the serialization/deserialization logic #36
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
Conversation
I really like this 'abstract' vision that you are implementing, because to me it seems it can help with reducing strong dependencies and adding some possibilities of customization. But in this particular case, I was just wondering: does it happen often that you want to swap from one Json library to another one? I'm not against it at all, I'm just asking because I think this introduces more complexity in the code and want to be sure it is indeed useful. I am used to developing in languages where you have either a native way of handling JSON, or a library that kind of is the main choice for everyone, but I don't know how Java developers handle this in general, I see there are a few options that are used widely and don't seem to have a real consensus. In the other hand, centralizing json handling seems like an amazing idea for usability and readability! 👍 Thanks @niemannd |
In the Java Ecosystem you have different userclusters that use different libraries. To not scare away a possible userbase i wrote this little abstraction to allow them to integrate an existing json library. In some environments "just pull in a second json lib" doesn't fly and will get you in trouble. I hope its not that big of a braintwister 😄 |
Thanks a lot! Your answer is quite reassuring, and it seems to be exactly what we want!!! Then again, I ask myself ( and to you in here :) ) the same question than for other abstactions... should we make a choice to use a specific library by default, to make it easy to use out-of-the-box? With an abstraction like this one you are introducing, this kind of choice is a big help instead of a constraint! That's great! I see you used gson, maybe because it was already used in this SDK, maybe because is your choice. But feel free to use a different one if you prefer |
fbf420c
to
2f270f1
Compare
I added two additional Handlers. JacksonJsonHandler that uses Jackson
Maybe we can automatically decide what implementation we use based on the classpath.
|
2f270f1
to
67cadb6
Compare
thats probably because the dependencies JacksonJsonHandler and JsonbJsonHandler need are compileOnly and not bundled with the dependency. To use them your need the following dependencies in your build.gradle |
Oh sorry, I deleted the comment as I realized that! Thanks for your help! Works smoothly 👍 |
@Test | ||
void serialize() throws Exception { | ||
assertEquals("test", classToTest.encode("test")); | ||
when(mapper.toJson(any(Movie.class))).thenThrow(new JsonbException("Oh boy!")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, great! 🌮
Ready to merge @niemannd ? |
Ready to merge |
Another question, sorry... Assumingimport com.meilisearch.sdk.Client;
import com.meilisearch.sdk.Config;
import com.meilisearch.sdk.UpdateStatus;
import com.meilisearch.sdk.Index;
import com.meilisearch.sdk.json.GsonJsonHandler;
import com.meilisearch.sdk.json.JacksonJsonHandler;
import com.meilisearch.sdk.json.JsonbJsonHandler;
final class Document {
String id;
String title;
}
final class Results {
Document[] hits;
}
public class TestJava {
public static void main(String[] args) throws Exception {
GsonJsonHandler json_gson = new GsonJsonHandler();
JacksonJsonHandler json_jackson = new JacksonJsonHandler();
JsonbJsonHandler json_jsonb = new JsonbJsonHandler();
final String indexUid = "books";
final String documents = "["
+ "{\"id\": 123, \"title\": \"Pride and Prejudice\"},"
+ "{\"id\": 456, \"title\": \"Le Petit Prince\"},"
+ "{\"id\": 1, \"title\": \"Alice In Wonderland\"},"
+ "{\"id\": 1344, \"title\": \"The Hobbit\"},"
+ "{\"id\": 4, \"title\": \"Harry Potter and the Half-Blood Prince\"},"
+ "{\"id\": 2, \"title\": \"The Hitchhiker\'s Guide to the Galaxy\"}"
+ "]";
Client client = new Client(new Config("http://localhost:7700", "masterKey"));
Index index = client.createIndex(indexUid);
UpdateStatus update = json_gson.decode(
index.addDocuments(documents),
UpdateStatus.class
);
index.waitForPendingUpdate(update.getUpdateId());
// .... HERE GOES THE TEST
//
//
// .... HERE GOES THE TEST
client.deleteIndex(indexUid);
}
} If I testResults res_gson = json_gson.decode(index.search("a"), Results.class);
System.out.println(res_gson.hits);
System.out.println(json_gson.encode(res_gson.hits)); I get the output:
Then I try:Results res_jackson = json_jackson.decode(index.search("a"), Results.class);
System.out.println(res_jackson.hits); and the output is:
This seems to be a problem, can you check please? |
Thats a problem with the way you declared those classes.
|
Great, sorry, as usual when you try to do things quickly you end up working double haha! I'd like to add an integration test for this, using the 3 json implementations, and adding an assertion to check that the hits are the same no matter what encoder/decoder you use. Could you add it to the PR? I can commit a test if you prefer< but I prefer that everythiong is tested to avoid future problems :) |
I added unit tests for the other two JsonHandler.
|
Amazing @niemannd 🚀 🚀 🚀 🚀 |
This PR provides a centralized json handling system.
The Idea is to use the same JsonHandler throughout the whole sdk, centralize the logic to serialize/deserialize and make it possible to change the underlying Json library without breaking changes.
This is the json pendant to #34
ATM the Code is not integrated anywhere. this would be topic for a future PR.
Usage would be