Ok.
I think I catch what some people were saying about trying to move databases to external areas.
The problem is that in the current Links code, a database handle can be grabbed from anywhere, and it's used for all different purposes.
For instance, if you grab a handle to access the Users table '/defs/Users.def'
that handle is also used for accessing the sessions table, and Editors, etc.
_THIS_ is where I think people have hit problems with the databases.
With my mods, I've moved to actually grabbing a database handle for each of the tables I want to use. I've avoided this -- until I tried to move the users tables out to a central database.
What's happening, is that you _really_ should grab a database handle for _each_ table you want to access, and not take short cuts, unless you have a reason... such as the tables _MUST_ be in the same database -- forever.
In this case, I want (need) the Users table to be a central database, but the Editors, sessions, and other features to be in the local table. I may find the Sessions table is better off in the USERS database, since it's an attribute of the 'User' object, but for now, with the cookies, it needs to be 'site specific'. "Editor" status is by "site", since it's not a true attribute of the "user" object,but is tied directly to that user entering a site. (this can be argued... certainly :) )
But, I thought I'd post this, since I think it may answer some of the problems people have had trying to move databases, and why things don't seem to work right.
It's really better to grab a $USER, $CATDB, $LINKDB, $VALDB,etc object and use those to properly access each table/object. (You don't _have_ to, but confusion ensues).
To use a single sessions table, outside of the main database, it would seem the following values (taken from my updated mod, not the stock routines) would have to be upgraded:
my $session_cookie = $in->cookie (
-name => 's',
-value => $session,
-expires => '+3h',
-path => '/',
-domain => $server_cookie_name
);
my $user_cookie = $in->cookie (
-name => 'Username',
-value => $user,
-expires => '+1y',
-path => '/',
-domain => $server_cookie_name
);my $server_cookie_name
Would have to turned into a routine, that would parse the $LINKS{server_name_or_ip} variable on whitespace, and then add the '.' to each token, and recreate the variable (or, just do it right the first time in the Links.pm file<G>)
But, the passed values would have to be: ".server1.com .server2.com .server3.com" for each of the servers that is part of the "allowed" network.
It gets a little complicated, but once set up, it should work without much fuss. One user database, and the cookie contains each of the allowed server names.
Anyway, I'm working on moving the user management to a separate database, and might have it working tonight, depending on how many places I have to do the "User" code stuff in.
If anyone has hit any other problems, please pass them on :)
But, I thought I'd post about the database handles thing, since that might be what's been biting some people unawares.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
I think I catch what some people were saying about trying to move databases to external areas.
The problem is that in the current Links code, a database handle can be grabbed from anywhere, and it's used for all different purposes.
For instance, if you grab a handle to access the Users table '/defs/Users.def'
that handle is also used for accessing the sessions table, and Editors, etc.
_THIS_ is where I think people have hit problems with the databases.
With my mods, I've moved to actually grabbing a database handle for each of the tables I want to use. I've avoided this -- until I tried to move the users tables out to a central database.
What's happening, is that you _really_ should grab a database handle for _each_ table you want to access, and not take short cuts, unless you have a reason... such as the tables _MUST_ be in the same database -- forever.
In this case, I want (need) the Users table to be a central database, but the Editors, sessions, and other features to be in the local table. I may find the Sessions table is better off in the USERS database, since it's an attribute of the 'User' object, but for now, with the cookies, it needs to be 'site specific'. "Editor" status is by "site", since it's not a true attribute of the "user" object,but is tied directly to that user entering a site. (this can be argued... certainly :) )
But, I thought I'd post this, since I think it may answer some of the problems people have had trying to move databases, and why things don't seem to work right.
It's really better to grab a $USER, $CATDB, $LINKDB, $VALDB,etc object and use those to properly access each table/object. (You don't _have_ to, but confusion ensues).
To use a single sessions table, outside of the main database, it would seem the following values (taken from my updated mod, not the stock routines) would have to be upgraded:
Code:
my $server_cookie_name = '.' . "$LINKS{server_name_or_ip}"; my $session_cookie = $in->cookie (
-name => 's',
-value => $session,
-expires => '+3h',
-path => '/',
-domain => $server_cookie_name
);
my $user_cookie = $in->cookie (
-name => 'Username',
-value => $user,
-expires => '+1y',
-path => '/',
-domain => $server_cookie_name
);
Would have to turned into a routine, that would parse the $LINKS{server_name_or_ip} variable on whitespace, and then add the '.' to each token, and recreate the variable (or, just do it right the first time in the Links.pm file<G>)
But, the passed values would have to be: ".server1.com .server2.com .server3.com" for each of the servers that is part of the "allowed" network.
It gets a little complicated, but once set up, it should work without much fuss. One user database, and the cookie contains each of the allowed server names.
Anyway, I'm working on moving the user management to a separate database, and might have it working tonight, depending on how many places I have to do the "User" code stuff in.
If anyone has hit any other problems, please pass them on :)
But, I thought I'd post about the database handles thing, since that might be what's been biting some people unawares.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
Integrated user database