diff --git a/documentation/src/main/asciidoc/introduction/Entities.adoc b/documentation/src/main/asciidoc/introduction/Entities.adoc index 295bf4f8b6..f3dbfc7d15 100644 --- a/documentation/src/main/asciidoc/introduction/Entities.adoc +++ b/documentation/src/main/asciidoc/introduction/Entities.adoc @@ -243,7 +243,7 @@ Values are generated using a database sequence defined as follows: create sequence seq_book start with 5 increment by 10 ---- -[IMPORTANT] +[CAUTION] // .Check the `initialValue` and `allocationSize` ==== If you let Hibernate export your database schema, the sequence definition will have the right `start with` and `increment` values. diff --git a/documentation/src/main/asciidoc/introduction/Interacting.adoc b/documentation/src/main/asciidoc/introduction/Interacting.adoc index e567ce4c9e..2a0c036795 100644 --- a/documentation/src/main/asciidoc/introduction/Interacting.adoc +++ b/documentation/src/main/asciidoc/introduction/Interacting.adoc @@ -532,7 +532,7 @@ query.select(book).where(where) Here, the classes `Book_` and `Author_` are classes generated by Hibernate's {generator}[JPA Metamodel Generator], which is documented in the {generator-guide}[User Guide]. -[NOTE] +[CAUTION] // .Injection attacks and criteria queries ==== Notice that we did not bother treating `titlePattern` and `namePattern` as parameters. diff --git a/documentation/src/main/asciidoc/introduction/Tuning.adoc b/documentation/src/main/asciidoc/introduction/Tuning.adoc index 4d31cc793f..9af66febf0 100644 --- a/documentation/src/main/asciidoc/introduction/Tuning.adoc +++ b/documentation/src/main/asciidoc/introduction/Tuning.adoc @@ -175,7 +175,7 @@ We must explicitly mark each entity that will be stored in the second-level cac But that's still not enough. Hibernate does not itself contain an implementation of a second-level cache, so it's necessary to configure an external _cache provider_. -[IMPORTANT] +[CAUTION] // .Caching is disabled by default ==== Caching is disabled by default. @@ -370,7 +370,7 @@ The `Cache` interface allows programmatic eviction of cached items. sf.getCache().evictEntityData(Book.class, bookId); ---- -[NOTE] +[CAUTION] // .Second-level cache management is not transaction-aware ==== Second-level cache management is not transaction-aware. @@ -428,7 +428,7 @@ NOTE: There's no `flush()` operation, and so `update()` is always explicit. In certain circumstances, this makes stateless sessions easier to work with, but with the caveat that a stateless session is much more vulnerable to data aliasing effects, since it's easy to get two non-identical Java objects which both represent the same row of a database table. -[IMPORTANT] +[CAUTION] ==== If you use `fetch()` in a stateless session, you can very easily obtain two objects representing the same database row! ====