Re: UID constrained to int, good time to refactor?

Aleksandar Vidakovic wrote:
> I think that we could have the two "versions" side by side... why don't
> we use "UserEnvironment.getLoginName()" as the new UID? I just checked
> svc-authentication-persist and svc-authorization-persist and I think
> there is not too much todo... my suggestion would be like this:
> 

I understand now and agree that we shouldn't break the existing 
interface.  But a LoginName principal already exists, and may or may not 
be the same as a UID.  Maybe we could use getUserID as tne new getUID?

> - set "getUid" to deprecated and add a "log.warn("...")"
> - add an additional column of type varchar in db table KeelGroupMembers
> - UserEnvironment.getGroups() must look for both group members that are
> "connected" with either UIDs (int) or LoginNames (String); if it finds
> members that use UIDs it should log a warning
> 
> This way we can use both at the same time.
> 
> Did I forget something?

I think you've got the right idea.  I've gotten now the new Maven build 
system working for me, with much help and guidance from Shash, and I'll 
start coding on this today (as soon as i get enough coffee in me).

thanks,
gene
> 
> Aleks
> 
> 
> On Wed, 2005-03-30 at 12:44 -0600, Gene wrote:
> 
>>Well, in looking at this, I'm afraid I'm not smart enough to make it 
>>more painless.
>>
>>The problem as I see it is that the UserEnvironment interface defines 
>>the getUID to return an int.  If we add a getUIDString method, and maybe 
>>catch and check for the NumberFormatException everywhere getUID is 
>>called we could have it both ways.  Existing projects that rely on int's 
>>would still work, and projects that need Strings could make the 
>>adjustment.  It doesn't seem very clean though, and I haven't actually 
>>put it into practice either, just thinking out loud.
>>
>>I also thought of an altered model service, svc-model-StringUIDModel or 
>>something,  that could rely on Strings, but I don't think that solves 
>>the issue though.  The authentication services still need to set a 
>>String UID for it to work.
>>
>>I'm VERY willing to do all the grunt work, code changing, testing, if 
>>anyone has better cleaner suggestions.  I personally would just change 
>>getUID to return a String, fix existing code, and be done.  Alas, I 
>>realize this effects many projects.
>>
>>This is one of the issues that caused me to switch from another popular 
>>framework.  My local app code got so out of sync with the release 
>>versions that it was too much hassle to get published updates.  But, in 
>>that case, I didn't have contrib rights to cvs.
>>
>>I'm still checking out all the maven build changes (what a monster!), 
>>and have that hurdle to clear before tackling the UID issue.
>>
>>Thanks for considering
>>gene
>>
>>Gene wrote:
>>
>>>
>>>Sasvata (Shash) Chatterjee wrote:
>>>
>>>
>>>>Gene,
>>>>
>>>>
>>>>>During this time of change with the build system, I'd like to bring 
>>>>>up again the fact that the User ID from the DefaultEnvironment is 
>>>>>defined as an int.  In my case at least, it is a problem, and I've 
>>>>>modified all the keel core code that references it to handle a string 
>>>>>(locally). Works great, and works with int's as well.  Would this be 
>>>>>a good time to update the changes?  Is there ever going to be a good 
>>>>>time for this?  A single sign on authentication service comes to mind 
>>>>>that would require a change like this.
>>>>>
>>>>>I've not switched to the new build system yet(looks awesome btw), as 
>>>>>it would break my project, and wanted to test the waters on this again.
>>>>
>>>>
>>>>
>>>>I think this is a good change to make, overall.  However, in contrast 
>>>>to the build-system changes, which for the most part deal with changes 
>>>>for the putting together of the app, this will actually break 
>>>>functionality.
>>>
>>>
>>>It definitely breaks things =0)
>>>
>>>  So, is there a way we can provide a migration for
>>>
>>>
>>>>exisitng deployments to ease the pain?  Either way, we should probably 
>>>>get it done sooner than later.
>>>
>>>
>>>I will start today checking out from cvs to get going with the maven 
>>>build system.  I will at the same time incorporate my changes locally, 
>>>and try to find some way to migrate a little less painfully.  I may need 
>>>some help, and I'll post here.
>>>
>>>THANKS ALL
>>>gene
>>>http://keelframework.org/documentation.shtml
>>>Keelgroup mailing list
>>>[email protected]
>>>http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
>>>
>>
>>http://keelframework.org/documentation.shtml
>>Keelgroup mailing list
>>[email protected]
>>http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
>>
http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com