One last thing Lukas. - Different Case:
Assume you have:
@Entity
@Table(name = Car.TABLE_NAME)
public class Car implements Serializable {
// some definitions etc...
}
Also You have
public interface CarRepository extends CrudRepository<Car, Long> {
}
*IN TEST* you are doing this:
@Transactional
public boolean areDataStored (){
Car audi = new Car();
audi.set(whatSoEver);
//since you have autowired thru constructor carRepository, you can call:
carRepository.save(audi);
//if you do something like, it returns values as expected.
carRepository.findById(1L)
//However if you try to get values thru dsl, you get nothing.
dsl.select or dsl.selectFrom(table(name(tableName))).fetchAny()
}
It looks like, that @transaction on spring level isn't finished (which is
not finished) and dsl is not capable to see the values. Is there any way
how to sync those 2 approaches ?
Thank you very much.
Dne pátek 19. října 2018 10:58:36 UTC+2 Lukas Eder napsal(a):
>
> The jOOQ integration tests have two lifecycles:
>
> 1. At the beginning of running a test suite, all the schemas are dropped
> and re-created according to a well known schema version
> 2. At the beginning of each test that follows a test that modified any
> data, the data in the schemas is deleted and re-created
>
> As Rafael mentioned, few databases have transactional DDL (e.g. PostgreSQL
> does), but even in PostgreSQL, there are cases where some statement doesn't
> work in a transaction. Of course, you could still try to work with your
> rollback based model in 80% of your tests, if you think that's faster for
> your case. In the case of jOOQ's integration tests, it was just too much of
> a pain, to get this right across 25 RDBMS.
>
> Interesting, I didn't know that Spring reused @Transactional in this way.
> Seems "clever", but confusing. In tests, @Transactional defaults to rolling
> back, and in non-tests, it defaults to committing? Anyway, the problem
> might be somewhere in your configuration. I cannot tell for sure what went
> wrong there. Also, I'm not sure if you can annotate your entire class
> as @Transactional, or if you have to do that on a test (method) basis.
>
> Hope this helps,
> Lukas
>
> On Thu, Oct 18, 2018 at 7:13 PM Rafael Ponte <[email protected]
> <javascript:>> wrote:
>
>> Hi guys,
>>
>> If I’m not wrong only few databases consider DDL as a transactional
>> statement (so you can rollback it). Maybe for H2 they’re not. You’d better
>> check the documentation!
>>
>> So your best alternative is cleaning the database up after each test. You
>> can do it through jUnit @After annotation or creating your own jUnit Rule.
>>
>> What do you think?
>> On Thu, 18 Oct 2018 at 13:38 <[email protected] <javascript:>> wrote:
>>
>>> Let's take a look from another view. Consider you want to test some db
>>> behavior such as insert, create, update, delete, and so one in test.
>>> Expectation is to have same db setup for all test with few default tables
>>> and data init. So what happen in 1 test should not affect another test.
>>> Truncating data is one thing, i believe that can be handled somehow, but
>>> what about created or deleted tables? How to rollback after each test
>>> created table or put back deleted table ?
>>>
>>> Regarding to @Transactional: Docs is saying: "If your test is
>>> @Transactional, it rolls back the transaction at the end of each test
>>> method by default." (Taken from
>>> https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html
>>> *). *
>>>
>>> Dne čtvrtek 18. října 2018 16:16:32 UTC+2 Lukas Eder napsal(a):
>>>>
>>>> Hello,
>>>>
>>>> That doesn't sound like how spring works. A @Transactional method will
>>>> always commit by default, or rollback on exception. But there is perhaps
>>>> some Spring/JUnit feature that extends JUnit in the desired way?
>>>>
>>>> I don't know spring well enough. Perhaps you can get an answer on Stack
>>>> Overflow:
>>>> https://stackoverflow.com
>>>>
>>>> Thanks,
>>>> Lukas
>>>>
>>>> On Thu, Oct 18, 2018 at 4:03 PM <[email protected]> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> We ran into problem in our integrationTest. We are using Spring Boot +
>>>>> Postgre +JPA(hibernate) + Jooq. Besides other things (like queries and so
>>>>> on) we are using DSLContext obj.(dsl) for creating some dynamic tables.
>>>>> Now
>>>>> our issue lays on integration Tests.
>>>>>
>>>>> For tests, we are using H2 db.
>>>>>
>>>>> All int. test extends this class def:
>>>>>
>>>>> ContextConfiguration
>>>>> @SpringBootTest(webEnvironment = RANDOM_PORT)
>>>>> @ActiveProfiles("test")
>>>>> @Transactional
>>>>> // We tried also @Rollback annotation doesn't work either.
>>>>> class IntTestWithContext extends Specification {
>>>>> .....
>>>>> .....
>>>>> }
>>>>>
>>>>> We have test, where we are trying to validate, that in some cases,
>>>>> table is created and for other actions is deleted.
>>>>> My understanding of @Transactional was, that after each test, all
>>>>> changes should be rollbacked to previous state. We had also annotation
>>>>> @Rollback for that purpose, but it doesn't worked either. Issue is when
>>>>> we
>>>>> run in our test: dsl.dropTableIfExists('DYNAMIC_TABLE_1').execute(); This
>>>>> script however triggers commit, which actually push all changes made in
>>>>> test into DB. When this test ends, then all what was commited is stored
>>>>> in
>>>>> h2 Db and make other test failing. My question is pretty straight
>>>>> forward.
>>>>> What can we do with this.
>>>>> Expected behavior is : using jooq in test with all changes rollbacked
>>>>> in the end of the test.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "jOOQ User Group" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>
>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "jOOQ User Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected] <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Rafael Ponte
>> TriadWorks | Formação Java
>> http://cursos.triadworks.com.br
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jOOQ User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
