I see many jobs are still explicitly configured to request a build on
slaves tagged as "OS1".
Please get rid of that: we have no longer any slave running on OS1,
some of the new slaves use the "OS1" label to allow a smooth migration
- but it's a lie and it's been a long time since we removed OS1.
HHH-12146 is about being able to enable/disable caching at various levels
in an entity hierarchy. E.g., given a hierarchy such as `Person` and
`Company` both extending `LegalEntity`, this would allow users to say that
only `Company` should be cached but not `Person` nor any other
`LegalEntity` sub
I tested it locally, and when publishing the jars to Maven local, the
JavaDoc is now included.
Don't know if there's anything to be done about it.
Vlad
On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero
wrote:
> +1 to merge it (if it works - which I didn't check)
>
> Some history can easily be f
Conceptually it sounds useful but I'm wondering about this being safe
to do in various more tricky mapping scenarios.
For example consider this case:
@Inheritance(...)
@Cache(...)
@Cacheable(true)
class LegalEntity {
...
}
@Cacheable(false)
class Person extends LegalEntity {
...
}
@Cach
Its not any different than `#get( LegalEntity.class, key )` in the old
config when key refers to a Person and Person is *not* in the cache simply
because it has not been loaded/saved via this SF.
On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero
wrote:
> Conceptually it sounds useful but I'm wond
And btw, this *has* to happen. JPA requires it and the 2.2 TCK tests for
it. So there is no "keep allowing caching at the root-level" option here
On Tue, Dec 12, 2017 at 12:44 PM Steve Ebersole wrote:
> Its not any different than `#get( LegalEntity.class, key )` in the old
> config when key r
We discussed this further in chat. For the sake of others reading, the
summary: I got confused about the risks of having multiple cache
regions for a single hierarchy; the proposal is *not* to have multiple
regions yet be able to exclude specific types from the (shared) region
of a type hierarchy.
Hi all,
there's a feature request about including the (currently missing) bits
to be able to use the Spatial queries in WildFly:
- https://issues.jboss.org/browse/WFLY-7524?focusedCommentId=13504172
I propose we start by including these in the modules we produce as
part of the Hibernate ORM rele
I think that's a great idea. Was just an oversight on my part.
On Tue, Dec 12, 2017 at 7:19 PM Sanne Grinovero wrote:
> Hi all,
>
> there's a feature request about including the (currently missing) bits
> to be able to use the Spatial queries in WildFly:
> - https://issues.jboss.org/browse/WFL
I have just pushed this work to the 5.3 branch. Tomorrow I will start
working on getting this all integrated with master (and branching 5.2
off). At that point we are pretty much ready for that first Beta, so let
me know if anyone notices anything awry - this is a pretty big change.
On Tue, Dec
Vlad, these changes cause some failures in the userguide tests[1]. This is
not completely unexpected since they seem to do caching-specific
assertions. However, for the life of me I cannot figure out how to run
these locally. The problem is the annotation processor for generating the
"JPA static
I just went ahead and did the same we do for the other modules.
On Tue, Dec 12, 2017 at 9:47 PM Steve Ebersole wrote:
> Vlad, these changes cause some failures in the userguide tests[1]. This
> is not completely unexpected since they seem to do caching-specific
> assertions. However, for the l
12 matches
Mail list logo
