On Tue, Jun 12, 2001 at 05:12:39PM -0500, Mike Haberman wrote:
>
> Now if you want to add arbitary data to the user that gets saved over
> crashes, I would say that the application user should either add
^^^^
I mean startup/shutdowns :) developer
I can think three ways to handle the blob/setPerm issue in User.
Remove the blob field AND
1. add a varchar to replace the blob. This of couse assumes
that most uses save ascii/text to the field and we develop
a parsing protocol to save/restore the name/value pairs.
2. push the setPerm to a pull utility. Here you must have
blob support, but we create a separate table that maps
user to blob:
{
userId FOREIGN KEY REFERENCES User
stuff blob
}
saveUtil.setPerm($user, $field, $data);
So if you use the setPerm method, then all you need to
do is make sure that the table is created and you config
the pull tool. The pull tool would register as a http
binding listener, so data will be saved across restarts.
3. If you want blob support, you extend User. Or you extend
User and add all the fields you want to save. In most cases
you already know how you use the setPerm method, so why not
just add those fields to the User object and use the get/set
methods like any other BO.
We can still call User.save() before the server goes down
in any case.
I like the combo of #2 and #3. The Util could be used as an
ad-hoc way during development. When the dust settles, add
the fields that you use to the User Object.
mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
