1 (edited by deadram 2006-09-13 19:46)

Topic: For 1.3 extetions

I suggest expanding the db abstraction layer. Many mods, atm, only support a few of the database types that punbb does support. With extra php and/or less sql, Any mod could support any database type that punbb support, without modification to the mod big_smile

ie: mod wants to create a table, so do something like this:

$db->create_table(
  array(
    array('id', 'DBLayer::INT', array('DBLayer::PRIMARY', 'DBLayer::UNIQUE', 'DBLayer::SIZE', '10')),
    array('username', 'DBLayer::VCHAR', array('DBLayer::SIZE', '255')),
    array('pid', 'DBLayer::INT')
  )
);

Much more compatible, eh? EH? EH?

In the meentime you could make up some "general rules" like for one ALL them dam mods should update thier headers

// ... snip
##   Works on PunBB:  1.2.x
##   Works with: mysql, mysqli, pgsql
// .. snip

Seriously! I meen walk through 200 lines of changes just to find out that the dam mod doesn't support sqlite ~.~

echo "deadram"; echo; fortune;

Re: For 1.3 extetions

That's not an extension, that's a complete and total rewrite creating an extensive abstraction system tongue
If a mod doesn't support SQLite, it can probably be rewritten rather easily (the issue is that MySQL is what more people have and thus it's easier to test on) assuming of course that it doesn't use MySQL only features

Re: For 1.3 extetions

Smartys wrote:

That's not an extension

I believe that what he meant was that such a change would be beneficial to extension development, not that it would make a good extension.

Looking for a certain modification for your forum? Please take a look here before posting.

4 (edited by Smartys 2006-09-13 21:14)

Re: For 1.3 extetions

Aha smile
meh, I personally don't think that an uber database abstraction layer is the way to go both in terms of adding bloat and because most mods should work in SQLite by default or just need a little editing tongue

Re: For 1.3 extetions

There will always be incompatibilities tongue
I don't really see any use in this, except maybe creating overhead on the DB layer.

6

Re: For 1.3 extetions

The idea of mods clearly stating which databases they work with (or don't work with) would seem to be sensible though.

Re: For 1.3 extetions

The problem is that some mod writers aren't experienced enough to realize there are more options tongue
Plus, there's no standard place to put the disclaimer.
And I've seen mods that aren't compatible with MySQL (case in point: PM mod doesn't work with newer versions of MySQL most likely due to strict mode) tongue

Re: For 1.3 extetions

Smartys wrote:

And I've seen mods that aren't compatible with MySQL (case in point: PM mod doesn't work with newer versions of MySQL most likely due to strict mode) tongue

I can vouch for this... sad

Re: For 1.3 extetions

Heh, I tend to use as little as possible MySQL proprietary functions, as I don't know them anyway ^^

Re: For 1.3 extetions

I suppose the added overhead of a db abstrction layer would be a bad thing... but adding in a litle spot to say what databases the mods been tested with is necessary for my brain to stop hurting tongue

echo "deadram"; echo; fortune;

11

Re: For 1.3 extetions

StevenBullen wrote:
Smartys wrote:

And I've seen mods that aren't compatible with MySQL (case in point: PM mod doesn't work with newer versions of MySQL most likely due to strict mode) tongue

I can vouch for this... sad

I read that the later versions of mySQL applied the ANSI standard more closely.



(Slightly OT, I have been trying to get a sql query to run on a copy of IPB 1.3 I have lying around. Seems that with LEFT JOIN the two tables preceding the join statement have to be bracketed because of the way mySQL 5 has been changed. If anyone wants to PM me I can talk further, but I don't want to derail the thread.)

"Reality is that which when you stop believing in it doesn't go away."