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

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:

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

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
> 
-- 
Aleksandar Vidakovic <[email protected]>

http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com