Avoiding duplication of dev/test configuration

[Yoann Rodiere]

Hi,

TL;DR: It's currently not easy to set the same config properties for both dev mode and tests in a way that's brief, safe, and straightforward. But in an ideal world, we would do just that in demos/documentation. A few ideas to fix this situation. Scroll down to "Solution 1" for proposals.

We've been discussing improvements of dev/test configuration on GitHub [1], and because the solutions we've been discussing so far may be controversial, I would like to ask your opinion.

What we're trying to provide is a way for developers to specify configuration properties common to dev/test, in a way that's *brief*, *safe*, and *straightforward*.

I'm approaching the problem from the perspective of demos and (more importantly) documentation, where all three requirements are equally important: we want Quarkus to look its best, we want to promote best practices, and we want to stick to the point.

It's a detail, but one that has its importance as it will often be one of the first things a newcomer sees of Quarkus.

I'll reproduce the example from the GitHub ticket: let's say a developer wants to set the following properties in both dev mode and tests, because they don't use dev-services for some reason. I'm using this example because it's simple and likely familiar to most people here, but please keep in mind there are similar situations with other extensions/properties, where setting properties to the same value for dev and tests makes sense.

```

quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
quarkus.datasource.username=testuser
quarkus.datasource.password=testpassword

```

This configuration, without profiles, is brief and straightforward, but we would set the properties in production as well, which in the case of quarkus.hibernate-orm.database.generation is (very) dangerous. So, this is unsafe, and promotes bad practices.

We could override dangerous/undesirable properties with the prod profile:

```

quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
quarkus.datasource.username=testuser
quarkus.datasource.password=testpassword

%prod.quarkus.hibernate-orm.database.generation=drop-and-create

```

But then it feels backwards: we're configuring our application for dev/test first, and prod as an afterthought. Shouldn't production be our main focus? Not to mention that this solution brings a high risk for developers to simply forget to "reset" properties in prod mode. So, this is arguably still unsafe.

We could explicitly set the properties with both the test and dev profile:

```

%test.quarkus.hibernate-orm.database.generation=drop-and-create
%test.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%test.quarkus.datasource.username=testuser
%test.quarkus.datasource.password=testpassword

%dev.quarkus.hibernate-orm.database.generation=drop-and-create
%dev.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%dev.quarkus.datasource.username=testuser
%dev.quarkus.datasource.password=testpassword

```

But obviously, that's very verbose. Not really something we would be proud to display in our documentation. Not to mention that, should we introduce an additional "integrationtest" profile [2], this would get even worse.

As a last we resort, we could rely on parent profiles [3] (basically inheritance):

```

%test.quarkus.config.profile.parent=nonprod
%dev.quarkus.config.profile.parent=nonprod
%nonprod.quarkus.hibernate-orm.database.generation=drop-and-create
%nonprod.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%nonprod.quarkus.datasource.username=testuser
%nonprod.quarkus.datasource.password=testpassword

```

It's relatively brief, it's safe, but I wouldn't say it's straightforward in the context of a demo/documentation. Let's keep in mind we're going to use that syntax in documentation addressing a large audience such as that of the Hibernate ORM extension. Do we really want to force the complete beginners in that audience to deal with explicit configuration profile inheritance right from the start, for the simplest examples?

"Bring me solutions, not problems", you say. Sure. Let's have a look at what we came up with so far; of course I'm open to suggestions :)

*Solution 1*: I initially suggested a special syntax to specify a single property for multiple profiles in a single line.

```

%[dev,test].quarkus.hibernate-orm.database.generation=drop-and-create
%[dev,test].quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%[dev,test].quarkus.datasource.username=testuser
%[dev,test].quarkus.datasource.password=testpassword

```

It's brief, it's safe, and *arguably* straightforward. It's also very explicit and doesn't rely on much magic, which is both a blessing and a curse (it will probably always stay backwards compatible, but there's not much room for evolution). Implementation might be a problem, though, in particular if we want to support this for file names too (application-dev-and-test.properties to affect both the dev and test profile? That feels a bit weird.) And of course, precedence, even if well-defined, might be a bit confusing (what if I set both %[dev,test].something and %dev.something?).

*Solution 2*: Perhaps more promising, we could introduce a *default* parent profile for both the dev and test profile, say "nonprod". Every property set in that profile would act as a default for both the dev profile and the test profile:

```

%nonprod.quarkus.hibernate-orm.database.generation=drop-and-create
%nonprod.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%nonprod.quarkus.datasource.username=testuser
%nonprod.quarkus.datasource.password=testpassword

```

Here the devil is in the details: while this *could* feel relatively straightforward even to complete beginners, it all depends on our ability to find an explicit name for this new parent profile. If the name is clear enough that just by reading the configuration, you understand it will affect both dev and tests, then it's great. Otherwise, the cure is worse than the disease. In that respect, "nonprod" is "meh" at best.

*Solution 3*: Roberto suggested something else: we could simply define the "dev" profile as the (default) parent for the "test" profile. Every property set in the dev profile would act as a default for the test profile:

```

%dev.quarkus.hibernate-orm.database.generation=drop-and-create
%dev.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%dev.quarkus.datasource.username=testuser
%dev.quarkus.datasource.password=testpassword

```

It's even simpler than the solution above, and it also feels intuitive.

The only downside is that this could lead to backwards incompatibility and headaches when someone wants to set a property in dev mode, but not in tests: for example I want to run tests again Dev Services, but dev mode against my local DB instance that was initialized from production data (assuming the legal/privacy context allows that, of course). Then we're back to the awkward solution of setting a property, then overriding it to reset it:

```
%dev.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%dev.quarkus.datasource.username=testuser
%dev.quarkus.datasource.password=testpassword

%test.quarkus.datasource.jdbc.url=
%test.quarkus.datasource.username=
%test.quarkus.datasource.password=

```

Thoughts, opinions?

Thanks.

[1] https://github.com/quarkusio/quarkus/issues/26283

[2] https://github.com/quarkusio/quarkus/issues/26279#issuecomment-1162896196

[3] https://quarkus.io/guides/config-reference#parent-profile

Yoann Rodière

Hibernate Team

yo...@hibernate.org

[Stephane Epardaud]

Should I comment here or on the discussion?

On Fri, 24 Jun 2022 at 10:29, Yoann Rodiere <yo...@hibernate.org> wrote:

*Solution 1*: I initially suggested a special syntax to specify a single property for multiple profiles in a single line.

```

%[dev,test].quarkus.hibernate-orm.database.generation=drop-and-create
%[dev,test].quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%[dev,test].quarkus.datasource.username=testuser
%[dev,test].quarkus.datasource.password=testpassword

```

Sounds useful even for use-cases outside of this particular example. I don't see why we wouldn't support this.

 

*Solution 2*: Perhaps more promising, we could introduce a *default* parent profile for both the dev and test profile, say "nonprod". Every property set in that profile would act as a default for both the dev profile and the test profile:

```

%nonprod.quarkus.hibernate-orm.database.generation=drop-and-create
%nonprod.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%nonprod.quarkus.datasource.username=testuser
%nonprod.quarkus.datasource.password=testpassword

```

Honestly, this feels like it should be a negative profile, to support all "non-X" profiles.

%!prod.quarkus.something=bar

%!dev.quarkus.something=bar

or even:

!prod.quarkus.something=bar

 So, want something truely controversial? In Play 1 I'm used to the template engine being applied to every place possible, including config. So if we run our config through Qute we could write:

{#if profile != PROD}

quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
quarkus.datasource.username=testuser
quarkus.datasource.password=testpassword

{/if}

Then we call it a day. Frankly, I always loved how elegant that was, and it supports way more use-cases wrt logic than we can think of ATM. The only downside is that we're going to be limited in terms of how many things you can use in the expressions, because I don't think we should allow things like CDI access at this point where the app is not even configured, and it's build time too. But it'd be pretty damn elegant and powerful.

[Yoann Rodiere]

> Should I comment here or on the discussion?

Here please, so that we can reach more people :)

Yoann Rodière

Hibernate Team

yo...@hibernate.org

[Stephane Epardaud]

Sorry, it probably wasn't clear, but I did add comments further down :)

--

Stéphane Épardaud

[Yoann Rodiere]

Thanks for having a look! Answers inline.

On Fri, Jun 24, 2022 at 11:31 AM Stephane Epardaud <stephane...@gmail.com> wrote:

Should I comment here or on the discussion?

On Fri, 24 Jun 2022 at 10:29, Yoann Rodiere <yo...@hibernate.org> wrote:

*Solution 1*: I initially suggested a special syntax to specify a single property for multiple profiles in a single line.

```

%[dev,test].quarkus.hibernate-orm.database.generation=drop-and-create
%[dev,test].quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%[dev,test].quarkus.datasource.username=testuser
%[dev,test].quarkus.datasource.password=testpassword

```

Sounds useful even for use-cases outside of this particular example. I don't see why we wouldn't support this.

Fine by me. That would address my use case.

 

 

*Solution 2*: Perhaps more promising, we could introduce a *default* parent profile for both the dev and test profile, say "nonprod". Every property set in that profile would act as a default for both the dev profile and the test profile:

```

%nonprod.quarkus.hibernate-orm.database.generation=drop-and-create
%nonprod.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
%nonprod.quarkus.datasource.username=testuser
%nonprod.quarkus.datasource.password=testpassword

```

Honestly, this feels like it should be a negative profile, to support all "non-X" profiles.

%!prod.quarkus.something=bar

%!dev.quarkus.something=bar

or even:

!prod.quarkus.something=bar

That's an interesting idea. I'd stick to the first syntax because it's a bit clearer that you're negating the profile, not the whole property (whatever that would mean).

Among the cons, there's the question of what "negating" a profile means. The "universe" of profiles can be expanded by users, including at runtime, thereby changing the effect of such a negation. For example if I enable a profile named "prod-aws" during the build, instead of "prod"... then will "quarkus.something" suddenly  be set? I think so, and while logical, that could be a surprise to many people.

Really, I suggested the name "nonprod" because I couldn't come up with a better name, but it's quite bad and ideally we would find a better name. Something that says "a profile enabled when I'm running quarkus in dev mode or testing, but not when deploying, be it in prod, staging, or whatever environment". Hard to put that in 4-5 characters, though. Maybe a native English speaker would have a great suggestion, I don't know.

 

 So, want something truely controversial? In Play 1 I'm used to the template engine being applied to every place possible, including config. So if we run our config through Qute we could write:

{#if profile != PROD}

quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
quarkus.datasource.username=testuser
quarkus.datasource.password=testpassword

{/if}

Then we call it a day. Frankly, I always loved how elegant that was, and it supports way more use-cases wrt logic than we can think of ATM. The only downside is that we're going to be limited in terms of how many things you can use in the expressions, because I don't think we should allow things like CDI access at this point where the app is not even configured, and it's build time too. But it'd be pretty damn elegant and powerful.

The idea of a preprocessor (because that's what it is, right?) seems appealing indeed, but that would amount to introducing a whole new way of handling profiles, completely orthogonal to the existing prefix-based (`%profile.`) mechanism. I'm worried this would result in fragmentation (some people use one way to configure profile, some use another), which is bad for developers because they become confused as to what they should use, and bad for us because of higher maintenance costs (especially if we can't "just" translate the preprocessor directives to prefixed properties).

I think this could have been a great idea back when Quarkus started, but now... It's more problematic.

[William Burke]

Verbosity/duplication has its merits too as you'll know exactly what config is set rather than having to weed through some inheritance or expression or macro structure.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAEqagpqsCf-p6m4hMKvosFKT3CyFgNsj9CaQKwKuxEP9xqs%2B5A%40mail.gmail.com.

--

Bill Burke

Red Hat

[Alexey Sharandin]

Maybe better to add aliases?

Something like

quarkus.profile.alias.banzaaaaaai=prod

quarkus.profie.alias.working=dev,test

and use this aliases in %xxx

пятница, 24 июня 2022 г. в 17:47:18 UTC+5:30, bbu...@redhat.com:

[Loïc MATHIEU]

Hi,

I like the %[dev,test] proxy, it's clear and easy to use.

The %nonprod is a bit strange (the name is not ideal but it's an other issue) having a default profile that is an aggregation of profile without the ability for someone to do the same is disturbing.

I also like the idea to offer more flexible profile setup with aliases and aggregated profile as Alexey suggested.

Stephane suggestion with pre-processor and of config file seems powerful but it may complicate things a lot.

Regards,

Loïc

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/a264e125-2d67-49ad-b59f-44d27161540fn%40googlegroups.com.

[Yoann Rodiere]

On Fri, Jun 24, 2022 at 9:55 PM Alexey Sharandin <san...@yandex.ru> wrote:

Maybe better to add aliases?

Something like

quarkus.profile.alias.banzaaaaaai=prod

quarkus.profie.alias.working=dev,test

That's very similar to parent profiles [1]. It may or may not be a worthwhile feature to add, but unfortunately if it's going to be explicit, it won't solve my problem, and if it's going to be implicit, then there's little to no advantage over using the (existing) feature of parent profiles.

On Mon, Jun 27, 2022 at 12:57 PM Loïc MATHIEU <loik...@gmail.com> wrote:

The %nonprod is a bit strange (the name is not ideal but it's an other issue)

 

Agreed, the name is not good at all. I needed a placeholder :)

 

having a default profile that is an aggregation of profile without the ability for someone to do the same is disturbing.

As I mentioned in my initial post, people do have the ability to do the same, with parent profiles [1]. The proposal is only to add a "default" parent profile for the test and dev profiles, because it's an advanced feature and we don't want to have to explain it in every single documentation page out there.

But it's starting to seem like %[dev,test] is winning, and I agree it sounds better for the purpose of demos/documentation: it avoids duplication without adding much complexity.

[1] https://quarkus.io/guides/config-reference#parent-profile

[Roberto Cortez]

Hi,

The parent.profile was added for this exact use case (and a few more).

For me is not a big deal to add it when I need it, but I can understand that it may distract you from your original goal when doing demos.

I’m not a big fan of introducing new syntax into the configuration names. We already use [ ] to represent indexed values for Collections. Yes it would be possible to support them for profiles, due to the leading %, but still, it doesn’t feel right to me to use very similar syntax for two different scenarios:

# already supported

my.property[0]=value

my.property.object[0].name=value

# with the proposal

%[dev,test].my.property[0]=value

%[dev,test].my.property.object[0].name=value

We are now specifying multiple values for a collection (profiles). So I guess that naturally, people will expect to be able to do things like these:

my.property.object[0].name=Bob

my.property.object[1].name=Alice

# multiple indexes separated by comma

my.property.object[0,1].surname=Doe

Now comes the fun part of environment variables:

_DEV_TEST_MY_PROPERTY

With a single profile per property, we just check the first segment for a valid active profile. With multiple ones we need to check the entire key:

%[dev,test].my.property=

%[dev,test,my].property=

%[dev,test,my,property]=

Unless we add yet, another syntax to delimit profiles in Environment Variables :)

Then we have the profile aware files (application-dev.properties, application-test.properties):

Right now you also have to duplicate the keys (if you don’t use the parent profile). The proposed solution is only solving the issue for properties in a single file, but what we are observing is people using more and more profile-aware files (because of large configuration files, and they are used to doing it with Spring). So, how to handle profile-aware files?

- The profile name contains both profiles?

- Can we have combinations of both single and combined profiles?

- Again, we need to define the convention (or syntax) to individually represent profiles in the file name: devAndtest can represent the individual's dev and test profile, but also the actual devAndtest profile.

For alias, in practice the parent.profile can be used in that way.

Finally,

Remember that every new syntax MUST work with every available configuration source and format.

I’m always happy to add new stuff. Quite frankly, we already have so many configuration options and alternatives that I want to be extremely careful when adding more.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVEzRGQ9rfH1fymzrpzNrtGFoVY%3Dp0PqUkFPPV6Mo1kVRQ%40mail.gmail.com.

[David Lloyd]

On Fri, Jun 24, 2022 at 4:31 AM Stephane Epardaud
<stephane...@gmail.com> wrote:
> On Fri, 24 Jun 2022 at 10:29, Yoann Rodiere <yo...@hibernate.org> wrote:
>>
>> *Solution 1*: I initially suggested a special syntax to specify a single property for multiple profiles in a single line.
>>
>> ```
>> %[dev,test].quarkus.hibernate-orm.database.generation=drop-and-create
>> %[dev,test].quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test
>> %[dev,test].quarkus.datasource.username=testuser
>> %[dev,test].quarkus.datasource.password=testpassword
>> ```
>
> Sounds useful even for use-cases outside of this particular example. I don't see why we wouldn't support this.

A qualified +1 from me (see below).

> Honestly, this feels like it should be a negative profile, to support all "non-X" profiles.
>
> %!prod.quarkus.something=bar
> %!dev.quarkus.something=bar

I agree, but my bikeshed paint color would be:

%~prod.quarkus.something=bar

On Mon, Jun 27, 2022 at 6:31 AM 'Roberto Cortez' via Quarkus
Development mailing list <quark...@googlegroups.com> wrote:
> The parent.profile was added for this exact use case (and a few more).
>
> For me is not a big deal to add it when I need it, but I can understand that it may distract you from your original goal when doing demos.
>
> I’m not a big fan of introducing new syntax into the configuration names. We already use [ ] to represent indexed values for Collections. Yes it would be possible to support them for profiles, due to the leading %, but still, it doesn’t feel right to me to use very similar syntax for two different scenarios:
>
> # already supported
> my.property[0]=value
> my.property.object[0].name=value
>
> # with the proposal
> %[dev,test].my.property[0]=value
> %[dev,test].my.property.object[0].name=value

That's fair, but to me it's no different than Java using {} for both
blocks and arrays, or C using `&` as both a unary address-of operator
and a binary bitwise-AND operator. The usage is clear from context.

> We are now specifying multiple values for a collection (profiles). So I guess that naturally, people will expect to be able to do things like these:
>
> my.property.object[0].name=Bob
> my.property.object[1].name=Alice
> # multiple indexes separated by comma
> my.property.object[0,1].surname=Doe

I don't envision that TBH. As I said it's pretty clear from context;
and if `[]` is really super problematic we could always use a
different bracketing character like:

%{dev,test}.my.property[0]=Foo

> Now comes the fun part of environment variables:
>
> _DEV_TEST_MY_PROPERTY

Is there a good reason to support profiles with environment variables
at all? It seems like you might use them to *select* the profile, but
it seems to me that they're very close to the "metal" of the
deployment environment to be provisionally qualifying properties with
profiles at that stage.

> With a single profile per property, we just check the first segment for a valid active profile. With multiple ones we need to check the entire key:
>
> %[dev,test].my.property=
> %[dev,test,my].property=
> %[dev,test,my,property]=

I guess if it were *necessary* to allow this with env vars, it would be:

__DEV_TEST__MY_PROPERTY=
__DEV_TEST_MY__PROPERTY=
__DEV_TEST_MY_PROPERTY_=

I wouldn't consider that a victory for usability, but it is at least
unambiguous and consistent with how we handle quoted properties.

> Then we have the profile aware files (application-dev.properties, application-test.properties):
>
> Right now you also have to duplicate the keys (if you don’t use the parent profile). The proposed solution is only solving the issue for properties in a single file, but what we are observing is people using more and more profile-aware files (because of large configuration files, and they are used to doing it with Spring). So, how to handle profile-aware files?

I would say, *don't*. It's a convenience for sure, for those who are
accustomed to it. But solving a problem in one area does not mean it
must be solved in all areas. Particularly, this feature is a good way
to let us be more opinionated: "you *can* do multiple files but it's
often better to do one".

> Remember that every new syntax MUST work with every available configuration source and format.

Better to say, there must be a syntax which allows each new feature to
be expressed in every available configuration source and format. Can
we express these syntaxes neatly in YAML, and secondary languages like
TOML or JSON?

> I’m always happy to add new stuff. Quite frankly, we already have so many configuration options and alternatives that I want to be extremely careful when adding more.

This is a fair point. Configuration has evolved quite a lot since the
initial release and it's getting a bit difficult to manage the ever
increasing complexity, so this is a factor that has to be considered.
--
- DML • he/him

[Alexey Loubyansky]

+1

> Remember that every new syntax MUST work with every available configuration source and format.

Better to say, there must be a syntax which allows each new feature to
be expressed in every available configuration source and format. Can
we express these syntaxes neatly in YAML, and secondary languages like
TOML or JSON?

> I’m always happy to add new stuff. Quite frankly, we already have so many configuration options and alternatives that I want to be extremely careful when adding more.

This is a fair point. Configuration has evolved quite a lot since the
initial release and it's getting a bit difficult to manage the ever
increasing complexity, so this is a factor that has to be considered.
--
- DML • he/him

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CANghgrRpdXKOO48e-5yn_oD1cG861xhRDgmaU42qHwe6zBi%2BPA%40mail.gmail.com.

[Loïc MATHIEU]

Hi,

I recently moved an application that uses custom test resources to devservices.
Due to the fact that it's split on multiple components, we prefer docker compose on dev than devservices.

So I ended up duplicating a bunch of configuration properties with %dev.prop and %prod.prop to make devservices work in test but not in dev as devservices didn't work if the property is set.

For this use case, having the ability to set a property for a list of profiles would be very helpful and I think this is very common for devservices.

Regards,

Loïc

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJ97idGjgUVZnojFJVKHdv65o8zHART%3D8vjErQxU91HQqpvX5A%40mail.gmail.com.

[Yoann Rodiere]

Thanks for this additional use case.

Based on feedback in this thread I think most are in favor of implementing the syntax %[test,dev] as described in the GitHub issue [1] (or maybe with different delimiters, e.g. ${test,dev}); the question is mostly who and when.

I'm not sure Roberto has time to work on this, so maybe I'll give it a try; worst case that'll provide a proof of concept that we can take as inspiration when implementing the real thing.

I don't even know where to start though, so I'm not sure I'll manage :) We'll see.

[1] https://github.com/quarkusio/quarkus/issues/26283

Yoann Rodière

Hibernate Team

yo...@hibernate.org

[Roberto Cortez]

No worries, I can do it, but probably only after my PTO (I’m away the next couple of weeks).

If you want to do it, the profile resolution is handled here:

https://github.com/smallrye/smallrye-config/blob/main/implementation/src/main/java/io/smallrye/config/ProfileConfigSourceInterceptor.java

Or if you can wait until I return :)

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAEqagprtyDzGHYiz-XJQnn6Oi0X4WdfzDRjNhWqi5rUz1LDxJw%40mail.gmail.com.

[Yoann Rodiere]

Thanks for the hint! Alright, I'll consider this low priority then. I may have a look anyway since it seems interesting :)

Yoann Rodière

Hibernate Team

yo...@hibernate.org