Multiple "prefixes'

bobbyg · Posted: Thu Dec 17, 2009 10:42 pm

One of the problems with some addons/modules are the sessions and separate login requirements. What about having flexible prefixes for certain files? And maybe adding fields (as in shopping cart modules( to the session file.

This could also help with running multiple sites off one database and would allow access to all the sites with one login.

This is simply stated and by no means suggesting that it would be that easy. This would require some serious evaluation of which files could be handled this.

fkelly · Posted: Fri Dec 18, 2009 12:07 pm

Some applications, such as the Menalto Gallery, already preface their tables with say 'G2" to have say, 'G2_sometable' for all their tables. This is not exactly the same thing as a prefix but it does the job of distinquishing their tables from the rest. Their tables still have the format of 'nuke_g2_sometable' though where "nuke" is your prefix. The code throughout all of the standard Nuke modules as well as the core code relies on prefix and/or user_prefix -- this is hard coded and would not be easy to change on a universal basis. In fact, the fact that some code doesn't (or didn't) access the the user tables with 'user_prefix' has been the source of a number of bugs we've had to fix over the past few years. It only shows up when someone chooses a different user_prefix than the prefix.

I know this doesn't address all the issues you raised but it's all I can think of off the top.

bobbyg · Posted: Fri Dec 18, 2009 1:28 pm

Because tables set up by various groups are not uniform it may be something that would only apply to "out of the box" for RavenNuke. Some are attempting to create a shopping cart for RavenNuke. Multiple prefix standards could be set for "out of the box" RavenNuke addressing one login file and one session file for "certified modules/addons".

Just an example: in the config.php
$prefix='nuke'
$prefix2='login'
$prefix3='session'

This would not interfere with other 'non-certified' modules added to the site.

Like I said this would take some serious evaluation and planning, but could be beneficial in the long run.

jakec · Posted: Sat Dec 19, 2009 5:19 am

Well Nuke/RN already supports multiple prefixes, so you can share a database and have multiple installations using the same login information.

See this in the config.php file:

$prefix = 'nuke';
$user_prefix = 'nuke';

There is nothing to stop module developers from using their own prefix, like Gallery.

bobbyg · Posted: Sat Dec 19, 2009 6:17 am

When you attempt to load zencart or oscommerce, you have separate login and sessions that have been a cause of problems. They also require an additional registration and login instead of using the current login and session from RN.

While RN does have those 2, maybe additional ones would be helpful in some cases. At first glance, many would say it is not necessary, but RN development has made major advances because Raven and the development team has taken an in-depth look at how it could be improved.

jakec · Posted: Sat Dec 19, 2009 7:51 am

Personally I believe that it is for the third party developer to develop their bridge/integration to use the RN tables for login etc. It would be very difficult for RN to include compatibility for all third party modules.

fkelly · Posted: Sat Dec 19, 2009 8:38 am

I agree with JakeC and would even go beyond that. I think it's a hopeless task. Think about it from the perspective of a system like Zencart. They start out to have a shopping cart, E-Commerce system. They need to have a login facility and a users table and perhaps some type of groups facility. There's no standard for a field name such as 'username' or 'userid' and various systems need various types of data on their users -- so users tables for different systems will have users tables with different numbers and types of fields. And throughout that Zencart (or other third party system) they will be using their user table data so "hardcoded" into their programs will be SQL statements such as SELECT FROM USERSwhatever WHERE username(or whatever) = etc etc etc. Now if you try to integrate it and have a single users table you are going to break their system.

Now in theory I'm all for "user convenience" and integration and the like and having to login to a dozen or more systems every day and remember dozens of passwords drives me to distraction. But I don't see really what the solution is and I'm very sure we aren't going to solve it with the resources we have to work on RN.