[keycloak-dev] implement JPA model

[Boleslaw Dawidowicz]

K. Should have written 'a bit' instead of 'a lot'. Sorry for that. Still my point remains. I think most of the headaches come from using it as a general purpose storage while it shouldn't be treated as such.

Bill I'm not saying you are wrong in your judgement that custom JPA store will serve you better - for what you are trying to do it certainly will. Just saying that the usecase for IDM store is wrong here and should be altered. Just keep IDM stuff there and nothing else. Keep the model simple.

Still then... It is your project and doing custom store is a sane shortcut atm. IMO it is slightly short sighted but thats just my judgement. You'll be able to easier maintain it and tune it now. Tradeoff is that PL could benefit from being consumed in KC in a proper way - and this would be beneficial for KC in the long run as well. I fear we'll see a lot of duplicated functionality in both projects. 

In the end all I'm saying is that PL integration will be needed. If not now than later. Additionally we would like to be able to come up with alternative storage implementation. And this is quite a strong requirement for us

>From mobile

Dnia 4 lis 2013 o godz. 21:12 Bill Burke <bburke at redhat.com> napisał(a):

> 
> 
>> 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