Skip to content

Cannot convert generic sub-document fields [DATAMONGO-1312] #2226

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

Closed
spring-projects-issues opened this issue Nov 3, 2015 · 3 comments
Closed
Assignees
Labels
in: mapping Mapping and conversion infrastructure type: bug A general bug

Comments

@spring-projects-issues
Copy link

Mircea Gaceanu opened DATAMONGO-1312 and commented

Precondition: Class structure with generic fields.
Expected: Generic fields should be mapped correctly.
Actual: In the following case, when I save CharFoo objects and then fetch it from DB, the generic field abstractFooField is converted back to a Character, but bar.field from the sub-document is converted to a String and not to a Character.

Data model:

@Document(collection = "foo")
public abstract class AbstractFoo<T> {

    @Id
    private String id;
    private T abstractFooField;
    private AbstractBar<T> bar;

    public AbstractFoo() {}

    public AbstractFoo(T abstractFooField, AbstractBar<T> bar) {
        this.abstractFooField = abstractFooField;
        this.bar = bar;
    }
}


public class CharFoo extends AbstractFoo<Character> {

    public CharFoo() {}

    public CharFoo(Character abstractFooField,
            AbstractBar<Character> bar) {
        super(abstractFooField, bar);
    }
}

@Document
public class AbstractBar<T> {
    public AbstractBar() {}
}

public class Bar<T> extends AbstractBar<T> {

    private T field;

    public Bar(T field) {
        this.field = field;
    }
}

Unit test:

@Test
public void givenGenericEntities_whenFindOne_thenReturnCorrectTypes() {
    // GIVEN
    Bar<Character> charBar = new Bar<>('A');
    CharFoo charFoo = new CharFoo('B', charBar);
    fooRepository.save(charFoo);

    // WHEN
    CharFoo dbCharFoo = charFooRepository.findOne(charFoo.getId());

    // THEN
    assertEquals("Field class should match", Character.class, dbCharFoo.getAbstractFooField().getClass());
    assertEquals("Field class from sub-class should match", Character.class, ((Bar) dbCharFoo.getBar()).getField()
            .getClass());
}

Result:

java.lang.AssertionError: Field class from sub-class should match 
Expected :class java.lang.Character
Actual   :class java.lang.String

MongoDB document:

{
    "_id" : ObjectId("54db485a06e70e8444a15291"),
    "_class" : "com.test.model.CharFoo",
    "abstractFooField" : "B",
    "bar" : {
        "_class" : "com.test.model.Bar",
        "field" : "A"
    }
}

I'm attaching also the test project (Intellij)


Affects: 1.8 GA (Gosling)

Reference URL: http://stackoverflow.com/questions/26630523/springdata-mongodb-convert-generic-sub-document-fields

Attachments:

Issue Links:

  • DATACMNS-783 TypeInformation should allow applying the generic context to a raw type
    ("depends on")

Backported to: 1.8.1 (Gosling SR1), 1.7.3 (Fowler SR3)

@spring-projects-issues
Copy link
Author

Oliver Drotbohm commented

Running mvn clean test on the sample project builds fine o.O

@spring-projects-issues
Copy link
Author

Mircea Gaceanu commented

Please try mvn clean verify on the version I'm attaching now

@spring-projects-issues
Copy link
Author

Oliver Drotbohm commented

I fixed DATACMNS-783 and got your example working with the patched version. We now create synthetical TypeInformation instances from the raw type detected in the document to be read and the current generics context to reestablish the missing type information. Could fix it in Spring Data Commons entirely which makes the fix back-portable into the maintenance releases for Gosling and Fowler, the former expected for early next week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: mapping Mapping and conversion infrastructure type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants