[Proposal] Unified post table

[Apogate]

As a concept for discussion, one fuckhuge post table that could store all the posts for multiple boards. By adding a board identifier column (which I believe exists already) and changing the way post numbers are generated, might have potential.

Possible benefits:

• Simplifies the post crosslinking system
• Broadens the scope of admin.php to be able to handle multiple boards from one point.
• Reduces the number of post caches to a single array, might open the door for new features.
• A more self-aware saguaro

Drawbacks:

• I am unsure how a potentially larger table of this concept would perform.
• The fact that it hasn't been done somewhere before (to my knowledge) tells me there's probably a reason why.
• Is a step away from Saguaro's historically not-a-chan-in-a-box stance

Might pursue this idea in a planned dependency-laden fork SaguaroPlus.

stackoverflow here i come

repod grant me your wisdom

[Apogate]

Pretty sure I brought this up before in irc, can't remember where though.

[RePod]

I think Yushe also brought this up in some capacity. I don't like the idea.

Individual boards do not need information about each other, they should only focus on their own data.

A more self-aware saguaro

Exactly, something it doesn't need to be. Multi-board installs walk a fine line but even then they're not sharing data just resources (the _core directory) to achieve consistent results.

There's also a potential security risk where manipulating information on one board could impact another. For instance, if they got SQL injection (per their SQL server's permissions) they could drop the whole table (or worse, obviously).

If you must proceed with it do it but don't make it default. Make it opt-in instead of out.

As for potential features, I cannot think of any that would be hard to implement otherwise.

[Apogate]

We'll keep this repo true to its original intentions then. I'm leaning towards adding this in a fork, could also be combined with the new variable-array-config for cases where changing config values on the fly would be useful (user generated boards etc.)

who knows where the future will take saguaro

[RePod]

(SELECT no,board FROM imgboard WHERE resto=0)
UNION
(SELECT no,board FROM imgboard2 WHERE resto=0)
ORDER BY no ASC

no	board
1	saguaro
1	saguaro2
2	saguaro
5	saguaro
7	saguaro2
...	...

There are two downsides to UNION at present:

• A single board cannot be self-aware and know of other boards.
  • Meaning dynamic UNION is weird until we solve that problem.
  • Basically if we knew what the other boards were, dynamic UNION is simple.
• We don't actually track where the rows come from, so even after UNION all we have is board to know a row's origins.

---

In regards to your pros/cons list, by using UNION respectively:

Pros:

• Remedy cross-linking.
  • Currently the board column is separate from the actual table name so we can't look further than this.
• Negligible since, once again, UNION.
• UNION returns a single result set as well.
  • And for all intents and purposes can be manipulated as such (ORDER, LIMIT, etc).

Cons:

• No individual board table will be any larger than it needs to be.
• Other software is probably using a similar approach by maintaining individual board tables and proxying them as such.
• Doesn't break "not-chan-in-a-box", as it still prioritizes single boards.

[Apogate]

Unions over a fuck ton of tables pose a technical limitation.