On 8/19/16 9:04 AM, Stian Thorgersen wrote:
>
>
> On 19 August 2016 at 14:57, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>
>
> On 8/19/16 2:34 AM, Stian Thorgersen wrote:
>>
>>
>> On 18 August 2016 at 19:26, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>>
>>
>> On 8/18/16 1:13 AM, Stian Thorgersen wrote:
>>> One problem with this approach is that you end up having a
>>> separate JDBC connection and transaction even if it uses
>>> the same database the Keycloak server uses.
>>>
>> Something we have to fix anyways. Its on my todo list.
>>
>>
>>
>>> Take a look at
>>>
https://github.com/keycloak/keycloak/tree/master/examples/providers/domai...
>>>
<
https://github.com/keycloak/keycloak/tree/master/examples/providers/domai...
>>> for example which allows adding custom entities to the main
>>> EntityManager.
>>>
>> I'm really not a big fan of this extension and this is
>> something I do not want to support for product ever.
>>
>>
>> Why, please elaborate? IMO it's a really nice and simple way to
>> add a few extra entities for custom providers.
> Are you going to make our JPA entity classes public? If not,
> what's the point of this extension? Now that we have real
> deployers, its now easier to write your own persistence unit.
> Take a look at the example:
>
>
> Has nothing to do with our entity classes. It allows users to easily
> register an extra entity in our persistence unit, so same connection
> and transaction and no need to create a persistence unit at all. It
> also has support for Liquibase so schema is update the same way as
> with our stuff. Users would then get the EntityManager from the
> JpaConnectionProvider and be able to get their custom entities from
> there.
>
> It's simpler than what you have. Doesn't work if folks want a
> different database and such though.
I disagree. Its not simpler than using standard EJB/JPA.
@PersistenceContext EntityManager em;
is simpler than
EntityManager em =
KeycloakSession.getProvider(JpaConnectionProvider.class);
Another reason standard EJB/JPA is simpler is that JpaConnectinProvider
*requires* the developer to know and write liquibase XML for their new
entities. This is a real pain in the ass. Standard JPA, the schema can
be created/updated automatically.
Bill