nested POJO extract #575
nested POJO extract #575
Conversation
tenpigs267
force-pushed
the
poc/nested-json-object
branch
from
8619efb
to
f15bfad
Compare
…7/langchain4j into poc/nested-json-object
tenpigs267
force-pushed
the
poc/nested-json-object
branch
from
f15bfad
to
bd0486a
Compare
|
I didn't seen there was already a PR (#513) for nested objects. |
…7/langchain4j into poc/nested-json-object
…r final fields + add unit tests for ServiceOutputParser.outputFormatInstructions
| if (name.equals("__$hits$__")) { | ||
| if (name.equals("__$hits$__") | ||
| || java.lang.reflect.Modifier.isStatic(field.getModifiers()) | ||
| || java.lang.reflect.Modifier.isFinal(field.getModifiers())) { |
There was a problem hiding this comment.
Unfortunately this line is severely breaking.
Consider ServiceOutputParserTest.Person: By simply making is class immutable (and adding a constructor so JSON deserialization works), outputFormatInstructions will not return {\n}.
Furthermore, the same problem occurs for Java Records.
I am not sure what the motivation for this line was, but I propose at the very least, it should be removed.
There was a problem hiding this comment.
@geoand thanks for the heads up! Does it break Quarkus extension?
There was a problem hiding this comment.
@tenpigs267 BTW it also does not work if you have a recursion. So if I define it like this:
class Person {
private String firstName;
private String lastName;
private LocalDate birthDate;
private List<Person> parents;It will go into endless recursion.
There was a problem hiding this comment.
@geoand thanks for the heads up! Does it break Quarkus extension?
It breaks some of our tests that use Java Records
There was a problem hiding this comment.
thanks @langchain4j for #620 and sry for that.
For the recursive thing I'am going to add a PR with the code going through all involved classes and generating a list a class (and test it with openAI)
Following #575, here is a PR which add a set of visited classes sot that each class structure is defined only once (only when it is the root element class that is re-used, it is then defined a second time (see outputFormatInstructions_PersonWithParents unit test for a comprehensible example) Approch I suggested on #575 seemed less natural (navigate through classes first and then generate classes structure)
This PR enhance ServiceOutPutParser allowing outputFormatInstructions to document nested objects in jsonStructure.
Integration tests have been modified to add a nested address object. Maybe a dedicated test would be better?