Nicht verwenden, löschen() auf CrudRepository

Ich bin mit der neuesten Frühjahrs - (4.0.4) und Hibernate (4.3.5) und spring-data-jpa (1.6.0) zum ersten mal und habe Probleme damit, das repository zu arbeiten, um auf eine MySQL-Tabelle zu schreiben oder Daten zu löschen. Es liest die Daten in Ordnung, aber wenn ich versuche zu löschen, passiert nichts. Dinge funktionieren, wenn ich eine H2-Datenbank, aber wenn ich wechsle meine Datenquelle zu einem MySQL-server, löschen " () aufhört zu arbeiten.

Frage 1: Warum ist nicht die CrudRepository sub-Klasse in der Lage, zu löschen von Zeilen aus meiner Tabelle Entität, wenn ich eine MySQL-Datenquelle, aber es funktioniert mit dem gleichen code, wenn ich eine H2-Datenquelle?

Kann ich Daten löschen, wenn ich Funktionen erstellen, wie dies in meiner sub-Klasse von CrudRepository:

public interface MyEntityRepository extends CrudRepository<MyEntity, Long> {
    @Modifying
    @Query("delete from MyEntity where entity_id = ?1")
    void delete(Long entityId);

    @Modifying
    @Query("delete from StageTeacher")
    void deleteAll();
}

Ich hoffe, ich bin etwas fehlt einfach. Aber in meinem unit-test-Klasse, ich habe diesen autowired-repository Referenz:

@Autowired
MyEntityRepository myEntityRepository;

Wenn ich mit der MySQL-Datenquelle diese Befehle tun nichts (Sie wissen nicht einmal Fall ein run-time error):

myEntityRepository.deleteAll();
myEntityRepository.delete(myEntity.getId());

Hier ist der 2 Datenquellen (H2 auskommentiert ist) und die entity manager factory erstellen ich mit diesem code:

@Bean
public EntityManagerFactory entityManagerFactory() throws SQLException {
    DriverManagerDataSource dataSource = new DriverManagerDataSource();
    dataSource.setDriverClassName("com.mysql.jdbc.Driver");
    dataSource.setUrl("jdbc:mysql://<host name>:3306/<schema name>");
    dataSource.setUsername("<username>");
    dataSource.setPassword("<password>");

    /*
    EmbeddedDatabaseBuilder builder = new EmbeddedDatabaseBuilder();
    DriverManagerDataSource dataSource = builder.setType(EmbeddedDatabaseType.H2).build();
    */

    HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter();
    //used when I have H2 enabled
    //vendorAdapter.setGenerateDdl(true);

    LocalContainerEntityManagerFactoryBean factory = new LocalContainerEntityManagerFactoryBean();
    factory.setJpaVendorAdapter(vendorAdapter);

    Properties properties = new Properties();
    properties.setProperty("hibernate.show_sql", "true");
    properties.setProperty("hibernate.dialect", "org.hibernate.dialect.MySQLMyISAMDialect");
    factory.setJpaProperties(properties);

    factory.setPackagesToScan("<package with table entity classes>");
    factory.setDataSource(dataSource);
    factory.afterPropertiesSet();

    return factory.getObject();
}

EDIT: habe ich noch folgende auf meiner log4j.xml:

<logger name="org.hibernate">
    <level value="DEBUG"/>
</logger>
<logger name="org.springframework.data">
    <level value="DEBUG"/>
</logger>

Bekomme ich diese in der Konsole wenn ich meine Methoden un-kommentiert im Repository sub-Klasse:

DEBUG [main] IntegrationTests.delete(54) | >>>>>>>>>> delete all??
DEBUG [main] AbstractTransactionImpl.begin(160) | begin
DEBUG [main] LogicalConnectionImpl.obtainConnection(226) | Obtaining JDBC connection
DEBUG [main] LogicalConnectionImpl.obtainConnection(232) | Obtained JDBC connection
DEBUG [main] JdbcTransaction.doBegin(69) | initial autocommit status: true
DEBUG [main] JdbcTransaction.doBegin(71) | disabling autocommit
Hibernate: delete from stage_teacher
DEBUG [main] AbstractTransactionImpl.commit(175) | committing
DEBUG [main] JdbcTransaction.doCommit(113) | committed JDBC Connection
DEBUG [main] JdbcTransaction.releaseManagedConnection(126) | re-enabling autocommit
DEBUG [main] LogicalConnectionImpl.releaseConnection(246) | Releasing JDBC connection
DEBUG [main] LogicalConnectionImpl.releaseConnection(264) | Released JDBC connection

und das löschen erfolgreich!

Jedoch, wenn ich die Kommentar-repository sub-Klasse die Methoden aus, ich Mach das in der Konsole:

DEBUG [main] IntegrationTests.delete(54) | >>>>>>>>>> delete??
DEBUG [main] AbstractTransactionImpl.begin(160) | begin
DEBUG [main] LogicalConnectionImpl.obtainConnection(226) | Obtaining JDBC connection
DEBUG [main] LogicalConnectionImpl.obtainConnection(232) | Obtained JDBC connection
DEBUG [main] JdbcTransaction.doBegin(69) | initial autocommit status: true
DEBUG [main] JdbcTransaction.doBegin(71) | disabling autocommit
Hibernate: select stageteach0_.entity_id as entity_i1_0_0_, stageteach0_.active as active2_0_0_, stageteach0_.alias as alias3_0_0_, stageteach0_.allow_marketing_emails as allow_ma4_0_0_, stageteach0_.allow_password_resets as allow_pa5_0_0_, stageteach0_.console_setting_id as console_6_0_0_, stageteach0_.date_created as date_cre7_0_0_, stageteach0_.date_deactivated as date_dea8_0_0_, stageteach0_.date_modified as date_mod9_0_0_, stageteach0_.default_role_id as default10_0_0_, stageteach0_.district_teacher_id as distric11_0_0_, stageteach0_.email_address as email_a12_0_0_, stageteach0_.first_name as first_n13_0_0_, stageteach0_.first_name_localized as first_n14_0_0_, stageteach0_.iid as iid15_0_0_, stageteach0_.last_name as last_na16_0_0_, stageteach0_.last_name_localized as last_na17_0_0_, stageteach0_.main_teacher_id as main_te18_0_0_, stageteach0_.password as passwor19_0_0_, stageteach0_.pref_language_id as pref_la20_0_0_, stageteach0_.rest_id as rest_id21_0_0_, stageteach0_.salutation_id as salutat22_0_0_, stageteach0_.school_teacher_id as school_23_0_0_, stageteach0_.status_id as status_24_0_0_, stageteach0_.tcd as tcd25_0_0_, stageteach0_.teacher_type_id as teacher26_0_0_, stageteach0_.username as usernam27_0_0_ from stage_teacher stageteach0_ where stageteach0_.entity_id=?
DEBUG [main] ResultSetProcessorImpl.extractResults(127) | Starting ResultSet row #0
DEBUG [main] EntityReferenceInitializerImpl.resolveEntityKey(142) | On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified
DEBUG [main] TwoPhaseLoad.doInitializeEntity(160) | Resolving associations for [org.mind.gen40.domain.gen40.StageTeacher#10956]
DEBUG [main] TwoPhaseLoad.doInitializeEntity(286) | Done materializing entity [org.mind.gen40.domain.gen40.StageTeacher#10956]
DEBUG [main] AbstractLoadPlanBasedEntityLoader.load(208) | Done entity load : org.mind.gen40.domain.gen40.StageTeacher#10956
DEBUG [main] AbstractTransactionImpl.commit(175) | committing
DEBUG [main] JdbcTransaction.doCommit(113) | committed JDBC Connection
DEBUG [main] JdbcTransaction.releaseManagedConnection(126) | re-enabling autocommit
DEBUG [main] LogicalConnectionImpl.releaseConnection(246) | Releasing JDBC connection
DEBUG [main] LogicalConnectionImpl.releaseConnection(264) | Released JDBC connection

Nicht den Fehler zu löschen, haben etwas zu tun mit dieser Botschaft?

On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified

Ich bin mir nicht sicher, was das bedeutet...

Frage 2: muss ich die sub-Klasse CrudRepository für jede Tabelle, die ich brauche basic CRUD-Operationen auf, oder kann ich eine Referenz auf die Tabelle entity-Klasse zu erstellen, die eine CrudRepository zur Laufzeit für eine bestimmte Tabelle?

Frage 3: Wenn ich manuell anlegen müssen meine delete-und insert-Methoden auf eine große Anzahl von CrudRepository sub-Klassen, gibt es Anregungen, auf die Erstellung der Tabelle Personen und DAO-oder repository-Klassen Tabellen in MySQL?

Was bedeutet "hört auf zu arbeiten" konkret? Sind Sie immer irgendwelche Ausnahmen? Schalten Sie Ihre Hibernate-SQL-Anmeldung (DEBUG level) und post von der eigentlichen SQL-Abfragen es ist Ausstellung.
Wenn ich nicht über die löschen - () und deleteAll() Methoden (mit jeweils die Änderung und Abfrage von Annotationen wie oben gezeigt) in der CrudRepository sub-Klasse, ich bin immer ohne Ausnahmen. Ohne meine Methoden im repository sub-Klasse, wenn ich meine unit-tests, die SQL läuft niemals zum löschen von Zeilen bei allen, aber es gibt keine Ausnahme oder Fehler entweder.
Kurbel bis die Protokollierung. Etwas, irgendwo wird erklären, warum es nicht weiter.
Was logging-system verwenden Sie? Wie sind Sie mit der Anwendung?
Ich habe es Anmeldung eine Tonne von Informationen, indem Sie diesen in meine log4j.xml: <logger name="org.Ruhezustand"> <level value="DEBUG"/> </logger> ... danke! Ich versuche zu Sortieren, durch dies, um zu sehen, die Protokollierung, die bezieht sich nur auf das löschen versuchen.
Möglicherweise müssen Sie auch das org.springframework.data wenn der delete-Operationen sind nie zu Überwintern.

InformationsquelleAutor webhammer | 2014-05-23

6

Habe ich entdeckt, dass das problem wurzelt in der Tatsache, daß ich meinen code mit unit Tests. Offenbar unit-tests sind setup als Transaktionen, die automatisch ein Rollback, aber ich kann nicht finden die Dokumentation zu unterstützen. Mein unit-test war die Erstellung einer Zeile in einer Tabelle und löschen die Zeile, die Sie basierend auf der ID. Es wurde immer scheitern, weil es war immer ein Rollback der Transaktion.

Wenn Sie brauchen, unit-tests, die eigentlich eine löschen, dann fügen Sie die rollback(false) Anmerkung damit Ihr unit-test-Methode sieht wie folgt aus:
```
@Autowired
MyEntityRepository myEntityRepository;

@Test
@Rollback(false)
public void createAndThenDeleteRow() {
    MyEntity testRecord = new TestRecord( "fake", "data" );
    TestRecord savedRecord = myEntityRepository.save( testRecord );
    Long id = savedRecord.getId();
    TestRecord loadedRecord = myEntityRepository.findOne( id );
    assertNotNull( loadedRecord );
    myEntityRepository.delete( id );
    TestRecord reloadedRecord = myEntityRepository.findOne( id );
    assertNull( reloadedRecord );
}
```
InformationsquelleAutor webhammer

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.