I just checked in a fix to the LastLogin problem (at least I think it should
fix it, let me know.)
TurbineUser loads the values of the columns in the Visitor table into the
Perm hashtable. It then writes the contents of the Perm hashtable back out
when it is unbound. So you should use the TurbineUser object to change
values in the Visitor table.
Of course, if this is undesired behavior you should extend TurbineUser and
override the valueUnbound method.
BTW, are you still using FreeMarker? I have pretty much finished separating
the template layout/nav/screen system (service) from the template engine
services. It is working for simple test cases of FM and WM. I just want to
clean it up a bit and look a bit more at the WM utils to make sure I am not
breaking something there.
John McNally
----- Original Message -----
From: Travis Low <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Friday, August 18, 2000 9:04 AM
Subject: Re: Visitor table oddities with MySQL
> Has no one seen this problem, or is it a dumb question? I worked
> around it by maintaining login/create/modify time information in a
> separate table, and updating myself upon login or logout. But I'm not
> thrilled about it.
>
> Incidentally, mySQL has a "feature" that the first TIMESTAMP column in
> any record is automagically updated with the current time whenever
> that record is modified in any way. Is that consistent with the
> intent of the Visitor.MODIFIED column?
>
> -- Travis
>
> Travis Low wrote:
> >
> > The application I'm developing has a "BrowseUsers" screen on which I
> > display the last login date and time. To display this information, I
> > retrieve the Visitor.LASTLOGIN for each user. For the turbine user
> > (default user), the value in LASTLOGIN is correct. For other users,
> > the LASTLOGIN value is correct only for the duration of the session.
> > After logging out, the value reverts to 20021130000000 (midnight
> > November 30, 2002 for some strange reason).
> >
> > So I ran some selects from the mysql interpreter. The results:
> >
> > mysql> select LOGINID,CREATED,MODIFIED,LASTLOGIN FROM Visitor;
> > +---------+---------+----------------+----------------+
> > | LOGINID | CREATED | MODIFIED | LASTLOGIN |
> > +---------+---------+----------------+----------------+
> > | turbine | NULL | 20000816162126 | 20000816162126 |
> > | kelly | NULL | 20000815171052 | 20021130000000 |
> >
> > Then I logged in as "kelly" and checked again:
> >
> > mysql> select LOGINID,CREATED,MODIFIED,LASTLOGIN FROM Visitor;
> > +---------+---------+----------------+----------------+
> > | LOGINID | CREATED | MODIFIED | LASTLOGIN |
> > +---------+---------+----------------+----------------+
> > | turbine | NULL | 20000816162126 | 20000816162126 |
> > | kelly | NULL | 20000816164941 | 20000816164941 |
> >
> > And then I logged out:
> >
> > mysql> select LOGINID,CREATED,MODIFIED,LASTLOGIN FROM Visitor;
> > +---------+---------+----------------+----------------+
> > | LOGINID | CREATED | MODIFIED | LASTLOGIN |
> > +---------+---------+----------------+----------------+
> > | turbine | NULL | 20000816162126 | 20000816162126 |
> > | kelly | NULL | 20000815171052 | 20021130000000 |
> >
> > Notice that both the MODIFIED and LASTLOGIN fields are restored to
> > their original values.
> >
> > I am using the org/apache/turbine/modules/actions/LogoutUser.java
> > action to do logout. It calls method saveToStorage() in
> > org/apache/turbine/om/user/peer/TurbineUserPeer.java. That method
> > looks like this:
> >
> > public void saveToStorage() throws Exception
> > {
> > // this is where we should save the permStorage hashtable
> > // to the database if we can get a connection to the database
> > // First any hashtable entries which have a column assigned
> > // are placed for storage in their respective column.
> > Hashtable permData = (Hashtable) getPermStorage().clone();
> > Criteria criteria = new Criteria();
> > criteria.add( TurbineUserPeer.VISITOR_ID, getId()
> > );
> >
> > for (int i=1; i<TurbineUserPeer.columnNames.length; i++ )
> > {
> > if (
> > permData.containsKey(TurbineUserPeer.criteriaKeys[i]) )
> > {
> > criteria.add( TurbineUserPeer.criteriaKeys[i],
> >
> > permData.remove(TurbineUserPeer.criteriaKeys[i]) );
> > }
> > }
> > criteria.add( TurbineUserPeer.OBJECT_DATA, permData
> > );
> > TurbineUserPeer.doUpdate(criteria);
> > }
> >
> > I didn't dig any deeper than that, because I don't know much about
> > using Criteria yet. Anyone know what's wrong? Is it a bug, or do I
> > have a configuration issue?
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
