DATA DI PRIMAVERA MONGODB Ignores _CLASS INFORMAZIONI

Question

Ho qualche problema usando Spring-Data-MongoDB 1.3.3.release e Java 1.6.

La mia configurazione è un po 'complicata perché devo affrontare i dati legacy, quindi ho un TypeMapper personalizzato (estendendo DefaultMongoTypeMapper) e due diverse combinazioni di convertitori di lettura / scrittura. Inoltre, uso @TypeAlias per impostare le informazioni _class nel database.

I modelli problematici sono costituiti da diversi elenchi nidificati, alcuni sono stati digitati come

List<DocumentValue>

.

MyObject potrebbe contenere un elenco di oggetti

List<Object>

.

che può contenere un altro oggetto DocumentValue.

Questa configurazione sembra funzionare, i test unitario funzionano senza problemi, la mappatura degli oggetti sembra abbastanza bella nel debugger. La mia applicazione è un'applicazione Web e sono in grado di scrivere DocumentValues in una raccolta, è presente le informazioni _class.

A quanto tempo non arresto del server (un tomcat nel mio caso), la mappatura degli oggetti funziona. Ma quando riavvio il server (avviare un nuovo JVM), gli oggetti DocumentValue non sono mappati correttamente ma vengono trattati come java.util.Map. Le informazioni _class sembrano ignorare. Suppongo che ci possa essere un problema con il mio contesto di mappatura (se le mie entità del modello siano registrate mentre iniziano il contesto di primavera?), Ma non sono in grado di trovare la configurazione errata. Qualcuno ha qualche problema simile o ha alcuni suggerimenti?

Answer 1

Grazie per la tua risposta. Penso di aver trovato il motivo per cui _class è stato ignorato. Hai ragione, uso una combinazione insolita di titimetro.

Lascia che ti mostri il mio personalizzatoPemapper:

public class CustomTypeMapper extends DefaultMongoTypeMapper {

    public CustomTypeMapper (MongoMappingContext mappingContext) {

        super(DEFAULT_TYPE_KEY,
                Arrays.asList(new MappingContextTypeInformationMapper(
                        mappingContext)));
    }

    @Override
    public <T> TypeInformation<? extends T> readType(DBObject source,
            TypeInformation<T> basicType) {

        // do some custom recognition

                // or just to the common type mapping
        return super.readType(source, basicType);

    }
}

.

Accanto al riconoscimento del tipo comune Una cosa speciale è il costruttore in cui un mappingContextTypeinformationMapper viene utilizzato per utilizzare le annotazioni di @typealias.

La chiave qui è il MongomappongContext che è necessario. Nella custodia non funzionale inizializzai il doganicazione come

<bean id="customTypeMapper" class="de.flexguse.repository.CustomTypeMapper">
    <constructor-arg name="mappingContext">
        <bean class="org.springframework.data.mongodb.core.mapping.MongoMappingContext" />
    </constructor-arg>
</bean>

.

che ha funzionato ma è stato sbagliato, poiché la nuova istanza di MongomappyContext non ha convinto alcuna tipoinformazione fornita impostando l'attributo del pacchetto base in

<mongo:mapping-converter id="customMappingConverter" db-factory-ref="mongoDbFactory"
        type-mapper-ref="customTypeMapper" base-package="de.flexguse.model" >

    <mongo:custom-converters>
            ... some custom converters ...
    </mongo:custom-converters>

</mongo:mapping-converter>

.

Purtroppo non sono stato in grado di capire dove viene creato il MongomappyContext per essere in grado di usarlo come argomento costruttore, quindi ho inventato un semplice fagiolo mongomappingContextProvider che ottiene il MongomappingContext usando @autowire

public class MongoMappingContextProvider {

    @Autowired
    private MongoMappingContext mappingContext;

    /**
     * @return the mappingContext
     */
    public MongoMappingContext getMappingContext() {
        return mappingContext;
    }

}

.

La configurazione della molla del dogantypemapper è simile a questo

<bean id="mongoMappingContextProvider" class="de.flexguse.repository.MongoMappingContextProvider" />

<bean id="customTypeMapper" class="de.flexguse.repository.CustomTypeMapper">
    <constructor-arg name="mappingContext" value="#{mongoMappingContextProvider.mappingContext}" />
</bean>

.

Questa soluzione funziona per me.

A proposito, per essere sicuro di avere tutte le specie di formazione per tutti i fagioli modello che uso ho aggiunto @Document a ogni fagiolo modello che è persistito - solo nel caso in cui;)

Forse questo è utile per qualcun altro con problemi simili.

Saluti, Christoph

Answer 2

Sospetto che il problema si verifichi a causa della combinazione insolita di utilizzo e convertitori TypeMapper. Se è registrata un'istanza Converter implementata manualmente per un particolare tipo, che Converter è responsabile della creazione di un oggetto persistevole e leggibile da e da mongodb.Ciò significa che la tua istanza del convertitore deve scrivere informazioni di tipo stesso.

Se non riesci a farlo funzionare e può compilare un piccolo progetto di esempio per riprodurre il problema (preferibilmente un caso di prova da eseguire), sentiti libero di archiviare un biglietto nel nostro https jira istanza.