ctudose/java-persistence-spring-data-hibernate

java-persistence-spring-data-hibernate's Issues

CH08-mapping-collections/bagofstrings: The ItemRepository.findImagesNative() does not return duplicates

bagofstrings

public interface ItemRepository extends JpaRepository<Item, Long> {
...
    Set<String> findImagesNative(Long id);     
}

Need to update return type "Collection<String>" as in Item

public class MappingCollectionsSpringDataJPATest {
...
        Set<String> images = itemRepository.findImagesNative(item.getId());
...
}

Need to update type "Collection<String>" as well

Thanks!

Ch18/hibernate-ogm code does not work

When I try to run the test class HibernateOGMTest I get for mongodb

javax.persistence.PersistenceException: Unable to build entity manager factory

main.HibernateOGMTest.setUp(HibernateOGMTest.java:26)

one of the warning says
WARN: HHH015016: Encountered a deprecated javax.persistence.spi.PersistenceProvider [org.hibernate.ejb.HibernatePersistence]; use [org.hibernate.jpa.HibernatePersistenceProvider] instead.

error out here
entityManagerFactory = Persistence.createEntityManagerFactory("ch18.hibernate_ogm");

persistence.xml & pom.xml are exact match as the source code so no typo there.

But when I changed to using neo4j instead of mongodb there is no error anymore and the tests pass.
can anyone confirm that the issue exists for them too?

`@NotNull`’s query behavior depends on the presence of `javax.el` dependency

Hello

For consistency of execution behavior between the main environment and the test environment, I would like to ask whether it would be better to add javax.el to the test dependency in an environment using Hibernate Validtor.

For example, in the eagerjoin example in Chapter 12, @NotNull is appended as follows:

• Item Entity - seller field

  @NotNull
  @ManyToOne(fetch = FetchType.EAGER) // Actually the default
  private User seller;

• EagerJoin in test - fetchEagerJoin()

  Item item = em.find(Item.class, ITEM_ID);
  // select i.*, u.*, b.*
  //  from ITEM i
  //   left outer join USERS u on u.ID = i.SELLER_ID
  //   left outer join BID b on b.ITEM_ID = i.ID
  //  where i.ID = ?

  The content of the executed query is included in the comment, and in relation to seller, it says that it was executed as a LEFT JOIN.

However, if you run the test after including the following content in pom.xml...

<dependency>
  <groupId>org.glassfish</groupId>
  <artifactId>javax.el</artifactId>
  <version>3.0.0</version>
  <scope>test</scope>
</dependency>

The execution result is as follows:

Hibernate: 
    select
        item0_.id as id1_1_0_,
        item0_.auctionEnd as auctione2_1_0_,
        item0_.name as name3_1_0_,
        item0_.seller_id as seller_i4_1_0_,
        bids1_.item_id as item_id4_0_1_,
        bids1_.id as id1_0_1_,
        bids1_.id as id1_0_2_,
        bids1_.amount as amount2_0_2_,
        bids1_.bidder_id as bidder_i3_0_2_,
        bids1_.item_id as item_id4_0_2_,
        user2_.id as id1_2_3_,
        user2_.username as username2_2_3_ 
    from
        Item item0_ 
    left outer join
        Bid bids1_ 
            on item0_.id=bids1_.item_id 
    inner join  -- // 💡Query executed with INNER JOIN for seller
        USERS user2_ 
            on item0_.seller_id=user2_.id 
    where
        item0_.id=?

In this case, @NotNull was processed normally and the INNER JOIN query was executed with the mandatory condition that the Item must contain a User.

Generally, in the main environment, javax.el is included in WAS such as Tomcat, so that part is likely to be executed as INNER JOIN.

I asked because I thought that if your project uses annotations such as Hibernate Validator and @NotNull, it would be better to add javax.el to the test dependencies in the test environment to ensure the same behavior as the main environment.

thank you have a good day. 👍

Typo in MetamodelTest

Typo in com.manning.javapersistence.ch03.metamodel.MetamodelTest line 125

Path<String> namePath = fromItem.get(Item_.name);

Should be

Path<String> namePath = fromItem.get("name");

noRollback test code in Chapter 11

hello.

Java Persistence with Spring Data and Hibernate has been published in Korea, so I am reading it well.

Among the example tests in Chapter 11, there is a noRollback test method as follows, but I am inquiring because it does not seem to be a test of the operation of noRollback.

java-persistence-spring-data-hibernate/Ch11/transactions5-springdata/src/test/java/com/manning/javapersistence/ch11/concurrency/TransactionPropagationTest.java

Lines 123 to 136 in 586c212

	@Test
	public void noRollback() {
	// no rollback - log message is persisted in the logs even after exception
	// because transaction was not rolled back
	itemRepository.addItemNoRollback("Item1", LocalDate.of(2022, 5, 1));
	itemRepository.addItemNoRollback("Item2", LocalDate.of(2022, 3, 1));
	itemRepository.addItemNoRollback("Item3", LocalDate.of(2022, 1, 1));
	DuplicateItemNameException ex = assertThrows(DuplicateItemNameException.class, () -> itemRepository.addItem("Item2", LocalDate.of(2016, 3, 1)));
	assertAll(
	() -> assertEquals("Item with name Item2 already exists", ex.getMessage()),
	() -> assertEquals(4, logRepository.findAll().size()),
	() -> assertEquals(3, itemRepository.findAll().size())
	);

Since noRollback is set in ItemRepository#addItemNoRollback() -> LogRepository#log(), it seems that there must be a scenario where duplication occurs when calling addItemNoRollback().

In the case of ItemRepository#addItem() in the middle, it seems to have no relation to setting noRollback because it is set to REQUIRED_NEW.

So I thought about the following test code:

 @Test 
 public void noRollback() { 
     itemRepository.addItemNoRollback("Item1", LocalDate.of(2022, 5, 1)); 
     itemRepository.addItemNoRollback("Item2", LocalDate.of(2022, 3, 1)); 
     
     DuplicateItemNameException ex = assertThrows(DuplicateItemNameException.class, () -> itemRepository.addItemNoRollback("Item2", LocalDate.of(2022, 1, 1))); 
     assertAll( 
             () -> assertEquals("Item with name Item2 already exists", ex.getMessage()), 
             () -> assertEquals(3, logRepository.findAll().size()), 
             () -> assertEquals(2, itemRepository.findAll().size()) 
     ); 
     // ...

Then, I will finish reading the book. I've read up to chapter 11 now..😅

thank you have a good day. 👍