[keycloak-dev] implement JPA model

[Pedro Igor Silva]

Hi Bill,

   Is this your JPA model ?

       https://github.com/keycloak/keycloak/tree/master/model/jpa/src/main/java/org/keycloak/models/jpa/entities

Regards.
Pedro Igor

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Monday, November 4, 2013 6:12:38 PM
Subject: Re: [keycloak-dev] implement JPA model



On 11/4/2013 10:58 AM, Bolesław Dawidowicz wrote:
> On 11/04/2013 04:46 PM, Bill Burke wrote:
>>
>>
>> On 11/4/2013 10:13 AM, Anil Saldhana wrote:
>>> On 11/04/2013 03:45 AM, Bolesław Dawidowicz wrote:
>>>> On 11/01/2013 04:17 PM, Anil Saldhana wrote:
>>>>> Bill,
>>>>>         this is just a cop out.
>>>>>
>>>>> You very well know this is just going to create more headache
>>>>> if ever KeyCloak is integrated into Wildfly. :)
>>>>>
>>>>> In future versions of WF (starting WF9), we want to make use of PL IDM
>>>>> for the user stores across the subsystems. That is the reason we are
>>>>> implementing a JDBC store implementation in addition to the JPA store when
>>>>> a database is involved.
>>>> How are you going to handle store implementation compatibility? JPA one
>>>> exposes great deal of flexibility by letting you to map your own
>>>> entities and shaping the model. I assume JDBC implementation will be
>>>> much more constrained and enforcing the model? I wonder what are the
>>>> odds that two applications reuse same identity store implementation if
>>>> they go beyond very basic schema.
>>>>
>>>> Going along this line... benefit for KC would be to integrate with IDM
>>>> storage that is already in place - JDBC one that you are implementing
>>>> would be natural fit to integrate with WF. Would be good to know the
>>>> limitations in advance to adapt.
>>> JDBC implementation is mainly for deeper WF integration. So if we
>>> standardize on PicketLink IDM across WF, then KeyCloak can reuse it
>>> to provide uniform dev experience.
>>>
>>
>> The problem with Picketlink IDM is that it is not a security solution.
>> It is a general purpose persistence solution.
>
> I think this is the main question to ask. Is it? I have impression that
> it was not meant to be but it kinda ended being used like this down the
> road.
>
> Maybe part of current issues is that PLIDM is abused as general purpose
> persistence solution. From the perspective of JPA store design I'm quite
> sure it will never be efficient one.
>
> Just to be fair... Looking back in time a lot of complexity was
> introduced into PLIDM by your request Bill ;)

You are rewriting history. My requests last summer were to make the 
existing PLIDM API usable.  i.e. adding removing partitions.  Don't try 
to hang the complexity of PLIDM on me...

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev