Create / Share a Topic in More Than One prefixed-Forum

twohawks · 2009-07-03 04:20:10

Hi Folks,
Well obviously I only get to come around anymore when the forum admins get feisty and ask me for [more] stuff :sigh:....

Firstly, its gets a little confusing using the word 'Forum' for a Fluxbb installation when discussing side-by-side (prefixed) installations since each one technically is said to be a forum, containing 'forums' containing topics, etc;
... so I am going to use the term "bbs" for unique installations, and 'forums' are those things that contain groupings of topics (etc, ad-nauseum)....

Here's the deal...
- Two Fluxbb 1.2.x bbs installations with unique prefixes.
- Unique Users in each 'bbs', but I have the admin and a couple other users setup as common users to each (just fyi),
- I do use the Categories mod to group forums,

The Admin wants to be able to create a unique Topic that will appear in both bbs's.
Currently I am fairly certain there exists no way (no plug in and no method previously discussed) for doing this.

*Q1* I am wondering what a bottomline list/collection of critical considerations for accomplishing this might look like_?

-----------------------------------------------------
Of course, an ideal scenario might be to be able to create 'shared forums' that could appear in both bbs's, within which the admin could create shared topics;
and to take it even further, to be able to also create shared Categories that these 'shared forums' could be assigned to.

However, right off the top I am thinking that may be a very complex undertaking,
and [if] so I wonder if the simplest approach may be to sort it out so that, for instance...
1 - the admin could create a forum with the same title in each bbs,
2 - I could go in and massage the database tables so the ID's for those forums are similar in the independent tables,
3 - so then when the admin adds a Topic to said forum it will then magically appear in both bbs's.

*Q2* Of course, I don't presume this (#3) is going to work "straight out of the gate", but I am wondering if there isn't something here that might proffer a simple solution ?
I imagine that if there is, might it possibly hinge on adding another field in the forums tables to be used for bridging the prefixed-bbs's?

Do you see where I am going with that? Its like, I see the 'barrier' as being the prefix, which is uniquely set in each installation, but maybe using a unique marker-field in the database forum tables could somehow be used to override this virtual barrier?

Please forgive I have not yet spent time back in the code to more closely think about this... I thought I'd come fishing here first. For all I know I am underthinking, or even overthinknig, it, ...or clearly not thinking at all?? !!

All righty then... lets see how ya'll bite on that ;^)

Cheers,

Last edited by twohawks (2009-07-03 04:21:14)

Franz · 2009-07-03 06:01:24

You would store the post only once, right?

twohawks · 2009-07-03 17:55:48

@lie2 -yes-

Franz · 2009-07-03 18:51:11

The only dirty thing I can come up with is to have two extra columns in one of the tables. One column would be "foreign_prefix" (with the prefix of the other posts table) and the other one would be "foreign_post_id", which would be NULL if the post is just a normal one. If it is an integer, it would represent the ID of the post in the other table. The problem with that is that everything else would probably have to be 0 or NULL (I don't know whether that's possible with the standard database structure).

You will have to change tons of queries...

twohawks · 2009-07-04 05:16:55

@Lie2 ...Hmm...

Another idea (while we think on this one): (again, I am not yet got around to looking at the code, just 'broad-stroke' musing )...
Usually you (can) set a single prefix when installing a bbs. In all the queries there is a variable placeholder for it. What if you could simply add a second one (or even more) and reconfigure the way the db.php parses the prefixes?

I think the prefix gets passed/parsed through the relevant dp.php when initially processed (so-to-speak... like on page load, etc).
I am wondering if I could make it so it would simply loop through 'the collection' of prefixes.
The idea would be to do something like install a third bbs with, say, a prefix of 'common' or something,
then add that prefix to the other two installations,
set things up so at the db parser it is looping through these...

...Of course, I have to think it through, but the idea would be to make the third bbs fully available in both the first and second ones, thus not having to sweat "changing tons of queries", only figuring out how to "somehow naturally" include forums and topics from the third.
Then all you might have to do is some coding to add the ability to select the third when creating the initial forum. Topics should naturally follow suit.

Of course, then you got to sort out the logic for users permissions, but if the idea has any sound basis then I think the method for handling this should shake out readily.

Something along those lines.
Is this making sense?

Last edited by twohawks (2009-07-04 05:20:19)

MattF · 2009-07-04 12:37:23

If it were me, (and I've understood you correctly), I'd merely create a specific forum or such on each where these topics are going to appear and create a wrapper function which fires up the DB layer with the correct connection info. The master BBS would contain the topic/post tables and the slave would fire up a db connection to connect to that masters topic/posts table when that designated forum on the slave is specified for viewing.

Franz · 2009-07-04 12:46:08

The prefixes are actually inserted into the query throughout the code. It's not done by the database layer.
For that idea you would probably have to do a UNION for every single query regarding posts, but that would probably not be the easiest solution - not by far.

MattF · 2009-07-04 12:52:37

lie2815 wrote:

The prefixes are actually inserted into the query throughout the code. It's not done by the database layer.

I might have explained a bit fuzzily what I meant. For topic insertion and suchlike, create a separate wrapper function in place of the standard $db->query, and use that wrapper instead. That wrapper then decides whether to connect 'locally' or 'remotely', and fires up the DBlayer connection, (or a second one if required), depending upon whether it is the master or slave, to connect to the appropriate DB.

Franz · 2009-07-04 13:00:24

I know. I was refering to twohawks' last post.

MattF · 2009-07-04 14:09:53

lie2815 wrote:

I know. I was refering to twohawks' last post.

Oops.

twohawks · 2009-07-04 18:29:44

@lie2 ..
The idea would be adjusting the entry in config.php to something like...
$db_prefix = array(main, common);
...so in effect I think all you would need to do is adjust the db function handling slightly, similar to what Matt has mentioned, but possibly even simpler (?).

By simpler what I mean is... it would seem you could then quite naturally/natively include the whole of the 3rd so-named "commonDB" in any other BBS, and it could be fully included for "normal" access *without fuss*... (meaning for searching and allowing all other base functions without needing to change any of them), and without worrying over isolating piecemeal access to forum-topics in another (say, the first or 'master") adjacent BBS, which seems, in this scenario anyway, might either limit some native functions or require more coding (??).

-----------------------------------------------------
@MattF: Interesting...
How would your wrapper be facilitated to decide/choose? I.e., where's it obtaining its directive-var from?
I would think it would have to be config.php -- is this your thinking?

And so then this wrapper function would be called "only in certain circumstances" and not universally all the time?

I am wondering if there isn't something betwen your idea and mine that is somewhat connected and may proffer an elegant *without fuss* solution??

MattF · 2009-07-04 22:48:46

twohawks wrote:

@MattF: Interesting...
How would your wrapper be facilitated to decide/choose? I.e., where's it obtaining its directive-var from?
I would think it would have to be config.php -- is this your thinking?
And so then this wrapper function would be called "only in certain circumstances" and not universally all the time?
I am wondering if there isn't something betwen your idea and mine that is somewhat connected and may proffer an elegant *without fuss* solution??

I've not spent a great deal of time thinking this one through, so the logic may be flawed, but generally something along the lines of:

function db_selector($query, $alt = false)
{
    if (!alt)
    {
        $db->query($query);
    }
    else
    {
        [insert code here for starting and using a transaction with a different DB];
    }
}

then just calling the function rather than $db directly and letting that select the DB depending on whether you set the $alt flag to true or not. A couple of minutes with sed or a similar tool would do any replacement needed in the files. As I say though, that could be completely flawed logic. I've not thought this one through for long. It was just the first thought that popped into my head when I read your post. (I'm sure it'll be dismissed rather quickly by someone if it is bunkum).

artoodetoo · 2009-07-05 04:48:20

The Admin wants to be able to create a unique Topic that will appear in both bbs's.

Does Admin want to get replies in both bbs? It seems to be much more complex then looks at a glance.

May be some sort of "feeds" from master bbs are better choise? Let some extra block in viewforum module to insert links to the master forum topics. They will looks like "sticked topics" at the top.

artoodetoo · 2009-07-05 04:53:53

viewforum.php

if (in_array($id, $master_ids) && $p == 1)
{
    include PUN_ROOT.'include/print-some-topic-subjects-from-master-bbs-with-refs-to-original.php';
}

twohawks · 2009-07-06 06:22:36

Please excuse the length of this post, but it seemed more appropriate in this instance to set sections in a single post rather than breaking it up...

1. BRIEF REPLIES
2. PONDERING FURTHER
3. NEW IDEA! (is it any good?)

=============================================================================
1. BRIEF REPONSES
@Matt: that's interesting. However, unless I missed something, it seems the question still remains "How would your wrapper be facilitated to decide/choose THE FORUM FROM THE OTHER BBS? I.e., where's it obtaining its INITIAL directive-var INFO from?"
I capitalized words I am adding here to try to make it less ambiguous.

So in your example, for instance, we do not know how or 'where/from' "alt" is intended to be intialized... how does the function know its gotta be 1 or 0?
And then where does the external db_table info get initialized?

***To be clear, I am more concerned with first discussing clarity to the general logicistics than worrying right now over any particular code or coding.**

Seems to me its critical to consider How any query is going to know it is being 'sent' anything from 'outside' the currrent BBS - where and how that is initially 'set' and 'held' for reference(?) Seems this will probably set the tone for decisions as to how anything shall be handled.

(...please read on, I had an idea...)

---------------------------------------------------
@r2d2:
1) yes to 'replies expected in both BBS's'.
2) Sorry, I posted and then I realized I misunderstood your post. I still may have it wrong, but it seems the intention might be to pull off the array I proposed for config.php?
If so, and maybe even if something else, sort of similar to my question with Matt's idea, how/where is the 'impetus' initially pulled from and then planted?

=============================================================================
2. PONDERING FURTHER.......

twohawks wrote:

The idea would be adjusting the entry in config.php to something like...
$db_prefix = array(main, common);
...so in effect I think all you would need to do is adjust the db(.php) function handling slightly

Please Check My Logic Here....(New idea in #3 hinges on this one)

So we have 'this'>BBS and 'that'>BBS and then 'common'>BBS, where 'this' and 'that' represent unique BBS's, and 'common' is a BBS created for sharing ALL its db-tables with both the other BBS's ...and so 'common' is not a BBS anyone ever logs into directly.

What initially occurs to me in this scenario is that, in effect, ...well, a couple things...

-1- 'common' BBS would only need to be setup for the sake of initial creation of its tables, and then its prefix added to the config file (per the above suggested array) of any BBS that will attach to forums and topics that may be later created in 'common',

-2- when the admin creates a forum from within 'this' or 'that' BBS, in order to designate it as a "shared" forum a method would need to have been created to facilitate choosing which BBS to place a new forum into ...say, the primary (native) one or the 'common' one for sharing purposes. (SideNote: the reason we would not have the admin log into 'common' BBS directly for doing this is because then he/she could not readily assign permissions, because no relevant users/groups actually exist in 'common' BBS)...,

-3- anytime a new forum is created in 'common' it will immediately appear in both 'this' and 'that' BBS's (because all 'common-forum-tables' are always referred to, just as natively as any primary/native tables are),

-4- hence, any topics or posts added from either BBS into any 'common-forum' would naturally appear in both BBS's.

-5- because the 'common' db-tablesets would be present and accessible as natively and commonly to either BBS where 'common' is added to its $db_prefix array --> each BBS could set its own unique users permissions in the normal way and without conflicts;
...for instance, in 'this-BBS' you could set user permissions like you would for any other primary/native forums that were created there, and there would be no conflict with doing exactly the same thing independently in 'that-BBS'.

-6- users in each BBS would see each other's handles, but be unable to view each other's profiles (acceptable) or non-shared topics/posts (of course).

---------------------------------------------------
Unless I have grossly overlooked something, this seems like an elegant, or at least simple and workable, solution(?WHAT DO YOU THINK?), that is, short of having better 'logical' clarity on Matt's or r2d2's suggestions ...as to where the initial tie-in is intended for the desired "other forum's tables" (and maybe its there and I missed it? sorry).

NOTED SHORTCOMINGs WITH THIS METHOD:
It would seem that if there was possiblity for an elegant solution that does not rely on creating another BBS tableset (e.c. 'common'), or impose any sharing limitations, ...that would be the ideal really.
Conversely to what I have proposed above, a third ('common') BBS doesn't facilitate "true sharing" of any forums that may pre-exist in already established working BBS's - which seems would more naturally and effectively serve an admin's needs.

For instance, one BBS has a discussion or lesson underway and now the admin wants to share that with another group (another school)..., my above proposed solution would require moving the forum to the 'common' BBS - maybe doable, but that may introduce too many undesired ramifications to deal with (haven't even begun to think about it).

....what to do... ? .... ? ... ? ....

=============================================================================
3. **NEW IDEA** : instead of intercepting db_query to try to solve this, will intercepting forum_ids provide a more wholisticly viable solution?
IF the proposed logic above has sound viability while maintaing a fair amount of its proposed simplicity..., then... being inspired by the excellent feedback so far and thinking harder about my questions regarding how to initially tie into another BBS's forums...
...PLEASE CHECK ME ON THIS IDEA -->>

Based on the logic for tying into a third 'common' BBS, how about selectively tying directly into any foreign forums you choose?...

---REQUIRES 3 LOGICAL MODS (?)----------------------------------------
Short Version:
1) Pull in a list of forums from the other BBS for the Admin to make selections from (in admin_forums.php),
2) When selected, a unique forum_id is generated same as when you create a new one, but additionally a unique decimal number is formulated for identifying the specific foreign forum, and then that decimal value is addended to the fid,
3) Then when any fid/f_id is called in a query, if it contains a decimal value a function parses the value for targeting whichever foreign forum is being referred to.
...after that, everything should follow suit without any modifications to queries or code...

Details:
1. Create a Method for the Admin to choose any foreign BBS Forum(s) from within admin_forums.php.
HowTo-Logic:
- Create a new array variable in config.php named $db_foreign_prefix: where you would input foreign prefix values.
- Create a table for storing unique values assigned to each foreign prefix, say for now, double-digit integer assignments starting at 10 (and auto-incrementing). (Have to create a simple function for generating the assignments when new entries aare found in the new variable.)
- In admin_forums.php (perhaps a plugin) create a section that will access, iterate, and list foreign BBS forums for the admin utilizing these $db_foreign_prefix table values,
- And create checkbox selection ability for these.
- Wont need a new page that facilitates setting options for ones that get selected because, by making the foreign forum selections appear native to the current BBS (see ahead) we'll be able to rely on all the existing native functions just as they are...

2. When a foreign BBS forum is selected for inclusion, then a unique id is added into the current BBS's "forums datatable", same as when you create a new forum, but with a twist...
HowTo-Logic... Challenge: create a unique id# that doesn't conflict, but in fact blends in, with native forum_id's (fid's or f_ids) auto-increment-numbering:
- upon selection of a foreign forum, allow the usual creation of a new auto_incrementing unique f_id (integer) assignment in the forum table for it,
- but then (new function) retrieve and augment that value with a unique re-calculated decimal value where the digits represent:
-- a)the foreign BBS's id listed in the above new table, and
-- b)the foreign BBS's forum_id addend to that.
...and then replace the unique id# in the table with this new one.

--> So for instance, say
- the new f_id auto-assignment = 101,
- the foreign BBS prefix value = 22, and
- the foreign BBS's f_id = 55 [and we'll be adjusting that to, say, 6-digits, so this final result = 000055]
...then the new f_id for this "attached-to foreign share" becomes: 101.22000050
...or something generally along those lines ***so that we can keep the native AND THE foreign forum_id assignments together in one-and-the-same forum table without having to augment the existing structure.

Now we would have a unique f_id that can be parsed to always reference a real external BBS's forum.

3. If this logic is not flawed, then it would seem all that's left is to add a function that parses any f_id (or fid) values when a db_query is initiated (perhaps simply in functions.php?).

If the unique decimal value is present in the f_id, it is parsed in order to "lock" on to a foreign forum as a top level reference for everything that follows (topics, posts, etc,),
...so it would seem nothing further would need to be fussed with. No db_query changes would be required anywhere. The only thing required is to cause our function to trigger anytime an fid/f_id is referenced in any query. I would presume to be setting this 'call' up in the relevant db.php file.

Solves the issue of not wanting to pull in all the forums from "the other BBS" everytime viewforums is loaded, or wrestling with how to isolate and access only 'shared' forums.
Solves the isolation issue imposed by using a 3rd 'common' BBS.

======================================================================
How's my logic holding up?
What do you think of the idea of this approach?

Last edited by twohawks (2009-07-06 10:46:57)

Franz · 2009-07-06 18:24:28

I think, your idea is the best.

First I had some problems with your additional database table, but thinking about it again, it makes much more sense - especially with not having to modify any other table...

One more thing, though: You have now taken care of forums, topics, and posts. That means you can simply change the db_prefix to the new prefix whenever a foreing forum ID is referenced (btw: I would rather do something like "22-55" - that way you don't have to mess around with the digits and IMHO it looks better). The problem that remains is what prefix are you using for tables like the user table?

MattF · 2009-07-07 06:40:32

Hell, I've lost the plot completely whilst reading your post, so for the moment I'll just answer the question you asked regarding the $alt var.

Some config file which contains all $db_info for an alternate connection and suchlike for creating a new DBlayer is in included in that conf file, plus the following:

$alternate_forum_ids = array(1, 2, 3, 4); //These are the shared forum id's.

viewforum.php, viewtopic.php, post.php, edit.php etc.:

require [alt config file path];

if (in_array($forum_id, alternate_forum_ids))
{
    $alt = '1';
}

twohawks · 2009-07-07 10:12:37

lie2815 wrote:

I think, your idea is the best.

I take it from your comments you mean "new idea" #3...

lie2815 wrote:

First I had some problems with your additional database table, but thinking about it again, it makes much more sense - especially with not having to modify any other table...

...or any native query codes in any of the 'view_xx.php' files. I find you reflection on that encouraging. It seemed trivial to me to add a small table for holding our data. Also facilitates auto creation of codes for any entries manually made in config.php for the new variable.

lie2815 wrote:

One more thing, though: You have now taken care of forums, topics, and posts. That means you can simply change the db_prefix to the new prefix whenever a foreing forum ID is referenced...
<snip>...The problem that remains is what prefix are you using for tables like the user table?...

Actually, if the logic isn't flawed, the method leads to not even ever having to change the native db_prefix at all, ever. No queries are edited. No need to.
The idea (which I think you already get) is that when f_id/fid in any query is referenced, at the point where it is passed on to the relevant db.php 'handler, there is an added function in there that intercepts the and looks at the f_id value for an addended decimal value... if its there then it gets decoded to the relevant foreign bbs->forum. At that point the proper foreign table reference is passed to the db handler. Because any following topic/post references hinge on the forum-reference they will naturally follow suit and populate with the correct foreign table references.
Make sense?

So Therefore, when a forum, foreign or domestic, is chosen by the administrator, user/group permissions are set the way they always are - there's nothing special required because the forum id that permissions reference... lives in the native table in exactly the same way as any native forum. Nice and neat... At least, that how it seems to me.

lie2815 wrote:

(btw: I would rather do something like "22-55" - that way you don't have to mess around with the digits and IMHO it looks better).

The reason I chose a full-on decimal digit is because (I think) that can easily be accomodated in the already existing (native) forum-table recordset structure for forum ids which is INTEGER..., so no editing of the table structure needs to take place in order for it to hold both native and foreign references together simply in the existing table. (I am waiting for someone to check me further on that, but it seems this is workable.)
And so of course, if we want to use the existing table-records this way then we cannot introduce any characters that will render the the value a non-integer.

Last edited by twohawks (2009-07-07 11:13:40)

twohawks · 2009-07-07 11:08:45

MattF wrote:

Hell, I've lost the plot completely whilst reading your post,

Hopefully some of my responses to 'lie2' will help some.

MattF wrote:

so for the moment I'll just answer the question you asked regarding the $alt var.
<snip>

Thanks for those clarifications. I think I get the idea(s) now.

I appreciate your time and reflections ;^)

Franz · 2009-07-07 14:12:05

*sigh* You just love long posts, don't you?

twohawks wrote:

lie2815 wrote:
I think, your idea is the best.
I take it from your comments you mean "new idea" #3...

Indeed.

twohawks wrote:

lie2815 wrote:
One more thing, though: You have now taken care of forums, topics, and posts. That means you can simply change the db_prefix to the new prefix whenever a foreing forum ID is referenced...
<snip>...The problem that remains is what prefix are you using for tables like the user table?...
Actually, if the logic isn't flawed, the method leads to not even ever having to change the native db_prefix at all, ever. No queries are edited. No need to.
The idea (which I think you already get) is that when f_id/fid in any query is referenced, at the point where it is passed on to the relevant db.php 'handler, there is an added function in there that intercepts the and looks at the f_id value for an addended decimal value... if its there then it gets decoded to the relevant foreign bbs->forum. At that point the proper foreign table reference is passed to the db handler. Because any following topic/post references hinge on the forum-reference they will naturally follow suit and populate with the correct foreign table references.
Make sense?

That's actually a pretty smart solution ( I like hacks ), although you would still hack the database layer, which I thought you wanted to avoid...

Nontheless, there still is the problems with users etc. Since users from both installs can post in that particular forum, you would have to use both forum tables in that query.
I have no clue about that, so is something like this possible: SELECT ... FROM (tableA UNION tableB)?

Also: Where would the decimal value come from? You would probably have to edit a link somewhere. If that link is supposed to be generated dynamically, again we would have a decimal value stored in the database (which is not possible right now -> you would have to mess with the database again). A more elegant and admin-friendly solution would be what, I think, Matt suggested: to have the possibility to let the admin mark a forum as a foreign forum. Ok, you would still have to add one column to the database table, but that's probably not avoidable completely and still better than messing up the existing stuff.
So, everytime we have a query for a forum, it is first checked whether that forum is a foreign forum. If yes, we fetch the db prefix and so on...

twohawks wrote:

So Therefore, when a forum, foreign or domestic, is chosen by the administrator, user/group permissions are set the way they always are - there's nothing special required because the forum id that permissions reference... lives in the native table in exactly the same way as any native forum. Nice and neat... At least, that how it seems to me.
lie2815 wrote:
(btw: I would rather do something like "22-55" - that way you don't have to mess around with the digits and IMHO it looks better).
The reason I chose a full-on decimal digit is because (I think) that can easily be accomodated in the already existing (native) forum-table recordset structure for forum ids which is INTEGER..., so no editing of the table structure needs to take place in order for it to hold both native and foreign references together simply in the existing table. (I am waiting for someone to check me further on that, but it seems this is workable.)
And so of course, if we want to use the existing table-records this way then we cannot introduce any characters that will render the the value a non-integer.

A decimal is not a valid integer.

EDIT: I think I am totally confused now...

Last edited by Franz (2009-07-07 14:12:30)

twohawks · 2009-07-07 19:56:09

I apologize for the long post[s] (and to you, as well, Smartys)... I have been "told" before.
I am trying to be sure that clear complete info is included so the whole picture becomes readily apparent.
I will try harder to be as succinct as possible...

lie2815 wrote:

Since users from both installs can post in that particular forum, you would have to use both forum tables in that query.

Nope. Think about it... when users at 'thisBBS' are accessing a forum, permissions management has nothing to do with anyone at any other BBS. Same thing applies over at 'thatBBS'.
The BBS doesn't care about managing foreign permissions. (see next)

lie2815 wrote:

Where would the decimal value come from?

Described in 3rd Section --> "NEW IDEA" / 'Details' / at #1. "Create a Method for the Admin to choose..." foreign forums with a checkbox.

To Re-Summarize My/The 2nd idea (skippable):
- In 3.1: in config.php any foriegn BBS prefix identifier-labels are manually assigned into a new array variable. Those get 'parsed' into a new table where they are given numeric labels. Those will later be pulled for use.
- In 3.2: Admin_forums.php plugin pulls in full foreignBBS forums into a list (based on new table data from 3.1) The admin is provided selecting via checkboxes.
- That foreign forum list has all the needed identification info including a numeric value that identifies a foreign BBS (in place of its prefix name ;^), and then also each foreign forum id number.
- When a foreign forum is selected, a query runs and the forums_table update runs in the usual way creating a 'f_id'...,
- A new function takes and tweaks that auto-assigned value into the new/unique 'identifier code' **using the foreign prefix + f_id numbers obtained above, and replaces the auto-generated f_id.

Lastly, since the forums are now included in the natural way (in the native forums table), permissions assignment can be handled normally.
- admin logs into 'thatBBS', creates a forum, sets permissions for her users there, etc...
- admin logs into 'thisBBS', picks a 'thatBBS forum, sets permissions as usual for her users here.

The BBS will only ever use its native prefix. Non-natives are always handled via an identifier-code. So when viewing and posting, the added db query function discovers and then parses any foreign identifier codes in order to query the correct tables.

lie2815 wrote:

A decimal is not a valid integer.

Hmmm... yeah, you are right. However, I was reading somewhere that sql will allow decimals to be placed into the Integer value structured records, ...I have to sort out if thats true.
That made me think, hey, the table always auto-updates one full ineger value, but we can change any value to a unique code by adding a fractional-decimal number. In this way there could always be full id-separation between foreign and native ...and right there within the native forum table.

If that won't work, then I think I would have to either...
1) create a new foreign forums table... but that would then change the method and require editing lots of queries,
OR
2) insert those new identifier numbers as integers either starting at some ridiculously high level (say 1,000,000,000), or using negative values, might do just as well.

...I am still pondering a couple other points you brought up...
Really appreciate these ideas and this feedback.

Last edited by twohawks (2009-07-07 23:29:03)

twohawks · 2009-07-07 23:27:31

lie2815 wrote:

Nontheless, there still is the problems with users etc. Since users from both installs can post in that particular forum, you would have to use both forum tables in that query.

In my second idea there is only ever one -native- forum table that is used, so normal native permissons may be applied without issue.

Matt's method appears to always reference the foreign table directly, so it is also dealing with "only one table", but because no unique records are being setup locally for the foreign forum there is no natural way (I have yet figured) to set native permissions for that. (a little more clarity appears below)

And if you meant BBS tables, I think I addressed this in the last post.

lie2815 wrote:

A more elegant and admin-friendly solution would be what, I think, Matt suggested: to have the possibility to let the admin mark a forum as a foreign forum. Ok, you would still have to add one column to the database table, but that's probably not avoidable completely and still better than messing up the existing stuff. So, everytime we have a query for a forum, it is first checked whether that forum is a foreign forum. If yes, we fetch the db prefix and so on...

Matt's ideas have been critically inspiring for me (thank you, Matt!).
I think Matt's suggestion implies you do not need to edit or add any tables. No column is added in the native forum table, and that no, the admin doesn't mark or choose foreign forums, you/me the coder set this manually in the config file.

------------------------------------------------------------
I am currently walking down some relevant scenario(s) using Matt's base ideas...
I think it best to wait on posting those, but it may do well to mention a couple things for clarity...

1) This line of reasoning appears to take off from my original [first post] suggestion, and requires that we first enter foreign BBS prefixes and forum_ids into the/a config file.
-- the admin doesn't have to choose foreign forums through an interface, they will simply and selectively be made available through Matt's "require", and
-- no forum table entries are made,
-- no special column for said "alt" flag is created because alt is set when running the code on any given page.

2) Upon view/post/edit/etc_xx.php page load, Matt's "require" pulls the foreign forums referencing in.

3) A wrapper function is setup to facilitate running queries with the foreign prefix + forums references (so queries run first natively, and then run wrapped). This could probably be done without wrapping each code instance, but implementing it somehow globally (say, at the db class).

This is how I am understanding and working on Matt's ideas.
I have worked up two or three (logical) method scenarios, and they look very compellingly simple and elegant, but I am wrestling slightly with permissions issues with this method.
However, there may be a method thats somewhat a cross between Matt's idea and my (the second) idea that can tame this issue, while also removing the need for the database hacks proposed in my 2nd idea ;^)

I want to keep this short for now, so there you go. If still relevant, I will share these 2 method workups later in the conversaton.

Last edited by twohawks (2009-07-07 23:33:57)

MattF · 2009-07-08 00:46:44

The permissions part is the simplest part. You do actually create a native forum and set the necessary permissions on that forum locally. However, you will never actually be referencing that forums content in the local table but rather the remote table, so you have the local permissions but the remote content. As soon as you reference that local forum id, that's when the wrapper kicks in.

twohawks · 2009-07-08 03:18:39

@Matt: Oh, okay.

MattF · 2009-07-08 03:45:36

Is that a good or bad okay?

In it's simplest form, (explanation wise), you create a forum on both BBS's. One will contain all of the content, the other will just be a placeholder as such. However, the fact that you have two physical forums allows the use of the permissions table locally on both BBS's, so you have granular control of whom can access from where. When you connect to the forum on the local machine, (when editing, posting, viewing etc.), it's connecting to the remote DB for the content of that forum, but checking the local permissions tables for the local placeholder forum which was created.

Forums

#1 2009-07-03 04:20:10

Create / Share a Topic in More Than One prefixed-Forum

#2 2009-07-03 06:01:24

Re: Create / Share a Topic in More Than One prefixed-Forum

#3 2009-07-03 17:55:48

Re: Create / Share a Topic in More Than One prefixed-Forum

#4 2009-07-03 18:51:11

Re: Create / Share a Topic in More Than One prefixed-Forum

#5 2009-07-04 05:16:55

Re: Create / Share a Topic in More Than One prefixed-Forum

#6 2009-07-04 12:37:23

Re: Create / Share a Topic in More Than One prefixed-Forum

#7 2009-07-04 12:46:08

Re: Create / Share a Topic in More Than One prefixed-Forum

#8 2009-07-04 12:52:37

Re: Create / Share a Topic in More Than One prefixed-Forum

#9 2009-07-04 13:00:24

Re: Create / Share a Topic in More Than One prefixed-Forum

#10 2009-07-04 14:09:53

Re: Create / Share a Topic in More Than One prefixed-Forum

#11 2009-07-04 18:29:44

Re: Create / Share a Topic in More Than One prefixed-Forum

#12 2009-07-04 22:48:46

Re: Create / Share a Topic in More Than One prefixed-Forum

#13 2009-07-05 04:48:20

Re: Create / Share a Topic in More Than One prefixed-Forum

#14 2009-07-05 04:53:53

Re: Create / Share a Topic in More Than One prefixed-Forum

#15 2009-07-06 06:22:36

Re: Create / Share a Topic in More Than One prefixed-Forum

#16 2009-07-06 18:24:28

Re: Create / Share a Topic in More Than One prefixed-Forum

#17 2009-07-07 06:40:32

Re: Create / Share a Topic in More Than One prefixed-Forum

#18 2009-07-07 10:12:37

Re: Create / Share a Topic in More Than One prefixed-Forum

#19 2009-07-07 11:08:45

Re: Create / Share a Topic in More Than One prefixed-Forum

#20 2009-07-07 14:12:05

Re: Create / Share a Topic in More Than One prefixed-Forum

#21 2009-07-07 19:56:09

Re: Create / Share a Topic in More Than One prefixed-Forum

#22 2009-07-07 23:27:31

Re: Create / Share a Topic in More Than One prefixed-Forum

#23 2009-07-08 00:46:44

Re: Create / Share a Topic in More Than One prefixed-Forum

#24 2009-07-08 03:18:39

Re: Create / Share a Topic in More Than One prefixed-Forum

#25 2009-07-08 03:45:36

Re: Create / Share a Topic in More Than One prefixed-Forum

Board footer