Объединить и получить версию, которая подлежит обновлению, без сброса?

Можно ли изменить экземпляр объекта с версией и получить версию для увеличения без использования флеша? Потому что из того, что я читал, я боюсь, что очистка - не лучшая практика, потому что это плохо сказывается на производительности или даже повреждении данных? Я не уверен: D

Вот простой код, а также вывод в виде комментария:

/*
    Hibernate: select receivingg0_.id as id9_14_, receivingg0_.creationDate as creation2_9_14_, ... too long
    the version before modification : 16
    the version after modification : 16
    after merge the modification, the version is : 16
    Hibernate: update ReceivingGood set creationDate=?, modificationDate=?, usercreate_id=?, usermodify_id=?,  ... too long
    after flushing the modification, the version is finally : 17
*/
public void modifyHeaderAndGetUpdatedVersion() {
    String id = "3b373f6a-9cd1-4c9c-9d46-240de37f6b0f";
    ReceivingGood receivingGood = em.find(ReceivingGood.class, id);
    System.out.println("the version before modification : " + receivingGood.getVersion());

    receivingGood.setTransactionNumber("NUM001xyz");
    System.out.println("the version after modification : " + receivingGood.getVersion());

    receivingGood = em.merge(receivingGood);
    System.out.println("after merge the modification, the version is : " + receivingGood.getVersion());

    em.flush();
    System.out.println("after flushing the modification, the version is finally : " + receivingGood.getVersion());
}

В моем тесте версия увеличивалась после сброса. Экземпляр, возвращенный из операции слияния, не имеет увеличенной версии.

Но в моем случае я хотел бы вернуть объект в свой webui в форме DTO, и объект должен иметь версию после сброса / фиксации перед преобразованием в DTO и возвратом в пользовательский интерфейс для визуализации. И тогда пользовательский интерфейс может иметь последнюю версию и будет передавать эту версию для следующей отправки.

Есть ли способ получить последнюю версию, не выполняя сброс?

Спасибо!

ОБНОВЛЕНИЕ

По моему опыту, увеличение этого числа вручную может быть проблематичным, как видно из приведенного ниже примера. В этом примере у нас 2 сброса.

Первый - синхронизировать изменения в соединении с базой данных, чтобы вызов хранимой процедуры из того же соединения мог видеть изменения, сделанные из entityManager.

Второй флеш вызывается для получения финальной версии. И мы видим, что это увеличивается вдвое . Таким образом, получение версии только из ручного приращения без промывки не будет работать в этом состоянии, так как мы должны действительно подсчитать, сколько выполняется сбросов.

/*
Hibernate: select receivingg0_.id as id9_14_, receivingg0_.creationDate as creation2_9_14_, .. too long
the version before modification : 18
the version after modification : 18
after merge the modification, the version is : 18
now flushing the modification, so that the stored procedure call from the same connection can see the changes
Hibernate: update ReceivingGood set creationDate=?, modificationDate=?, usercreate_id=?, .. too long
after flushing the modification, the version is : 19
Hibernate: update ReceivingGood set creationDate=?, modificationDate=?, usercreate_id=?, .. too long
after the second flush, the version got increased again into : 20
*/
public void modifyHeaderAndGetUpdatedVersionWith2Flushes() {
    String id = "3b373f6a-9cd1-4c9c-9d46-240de37f6b0f";
    ReceivingGood receivingGood = em.find(ReceivingGood.class, id);
    System.out.println("the version before modification : " + receivingGood.getVersion());

    //auditEntity(receivingGood, getUser("3978fee3-9690-4377-84bd-9fb05928a6fc"));
    receivingGood.setTransactionNumber("NUM001xyz");
    System.out.println("the version after modification : " + receivingGood.getVersion());

    receivingGood = em.merge(receivingGood);
    System.out.println("after merge the modification, the version is : " + receivingGood.getVersion());
    System.out.println("now flushing the modification, so that the stored procedure call from the same connection can see the changes");
    em.flush();
    System.out.println("after flushing the modification, the version is : " + receivingGood.getVersion());

    receivingGood.setTransactionNumber("NUM001abc");

    em.flush();
    System.out.println("after the second flush, the version got increased again into : " + receivingGood.getVersion());
}

Означает ли это, что мне действительно нужно полагаться на флеш в конце, чтобы получить последнюю версия для измененного объекта?

ОБНОВЛЕНИЕ 2

Здесь ' [core] editor = vim excludefiles = /home/augustin/.gitignore $ cat ~ / .gitignore toto $ mkdir git_test $ cd git_test / $ git init $ touch toto $ git status # On ...

$ cat ~/.gitconfig
[core]
        editor = vim
        excludefiles = /home/augustin/.gitignore
$ cat ~/.gitignore
toto
$ mkdir git_test
$ cd git_test/
$ git init
$ touch toto
$ git status

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       toto
nothing added to commit but untracked files present (use "git add" to track)
$ git --version
git version 1.6.3.3

Почему toto не игнорируется?

Учитываются другие настройки в ~ / .gitconfig (цвета, редактор).