Because the existing cache is global, there is no way to differentiate between
each of two databases which may be two different DBAL objects pointing to
servers with wildly different versions of an RDBMS. phpBB only has this
situation in the UCF, thus only one file changed outside the DBAL. I have
added a second optional parameter, $use_cache to each of the implementations
of dbal::sql_server_info()
PHPBB3-9637
This reverts Oracle support to the state it was in prior to phpBB 3.0.6. That is, storage of long strings works again (e.g. posts > 4 KB), but the database backup/restore functionality is broken. We feel that the ability to store long strings is more important than the DB restore, since Oracle 10g itself provides tools for backing up databases.
PHPBB3-9132
Generally, our config table is not really suited for holding large datasets. Because feed settings for the forums to enable news feeds and excluded forums rely on the forums itself we have decided to introduce a forum_options table where custom options can be stored.
Additionally, for this to work across all DBMS we support, we added a new method to the DBAL for the bitwise AND operator.
Also moved the forum/topic feed template variable to the location where they belong to (forum and topic view)
git-svn-id: file:///svn/phpbb/branches/phpBB-3_0_0@9965 89ea8834-ac86-4346-8a33-228a782c2dd0
Store it on installation too - allows us to check the db version used on installation and used currently to warn the user about incompatibilities
git-svn-id: file:///svn/phpbb/branches/phpBB-3_0_0@8814 89ea8834-ac86-4346-8a33-228a782c2dd0
- Firebird explodes when you deal with single column update/inserts over 32767, we now turn these queries into prepared statements
git-svn-id: file:///svn/phpbb/trunk@7326 89ea8834-ac86-4346-8a33-228a782c2dd0
- clean up firebird, I will consider changing it to use fetch array instead of fetch object. it's identity code already uses this method as of right... now :D
- fix a tiny bug in MySQL's driver (remember to pass the connect id to all DBAL functions)
- add new_link as a new param for sql_connect. This allows you to make connections that are not dependant on each other. This is done for our friends mysql, mssql, postgresql and oracle. Now for everybody else.. (I said this was clever ;) MySQLi and SQLite should always spawn a new connection when you call it while mssql_odbc and firebird both will create new links if you give them different params (different creds) than the previous connection(s). Thus we can always promise new links :D
- fixed a bug in the converter
- cleaned up the dbal a little
git-svn-id: file:///svn/phpbb/trunk@7009 89ea8834-ac86-4346-8a33-228a782c2dd0
- this sucker required a cleverish regex, there should be no further problems. it is also optimized :D
git-svn-id: file:///svn/phpbb/trunk@6959 89ea8834-ac86-4346-8a33-228a782c2dd0
major speed boost for Oracle :D
This took a while, every call to sql_query_limit() was checked out for having any implicit/explicit column issues... Hopefully, nothing has changed :D
git-svn-id: file:///svn/phpbb/trunk@6631 89ea8834-ac86-4346-8a33-228a782c2dd0
- new method sql_multi_insert to circumvent db-specific hacks
(hopefully not introduced any parsing errors)
git-svn-id: file:///svn/phpbb/trunk@6497 89ea8834-ac86-4346-8a33-228a782c2dd0
- sql_fetchfield now in dbal.php
- check query id correctly as well as other tiny fixes
git-svn-id: file:///svn/phpbb/trunk@6439 89ea8834-ac86-4346-8a33-228a782c2dd0
- MSSQL now works :P (sans UTF-8 support)
- The current schema files work well enough to install, etc. but must be tightened. Will get to it when I get some time...
git-svn-id: file:///svn/phpbb/trunk@6381 89ea8834-ac86-4346-8a33-228a782c2dd0
- all dbals adjusted to use the cache in sql_fetchfield, sql_rowseek, sql_numrows and sql_freeresult [Bug #2451]
- use include_once for dbal.php to at least theoretically allow connections to multiple databases at once
- added a space to an SQL query [Bug #3506]
- detailed information on adding friends/foes [Bugs #2509, #2499]
- e modifier stands for evil, so I removed it ;-)
- corrected progress_bar image filename in imageset.cfg [Bug #3374]
git-svn-id: file:///svn/phpbb/trunk@6225 89ea8834-ac86-4346-8a33-228a782c2dd0
- Make MySQL schema a little different than the others...
- Fix MCP_TOPIC
git-svn-id: file:///svn/phpbb/trunk@6212 89ea8834-ac86-4346-8a33-228a782c2dd0
Long story: Expanding the implicitly defined columns to explicitly defined columns lets us determine which columns we are actually grabbing. This lets us avoid the problem of having two columns having the same name even though one is implicit and the other is explicit.
What does this mean? It means that when doing a limit on Oracle with an implicit column and a bunch of explicit columns, the explicit columns are the ones that "win".
git-svn-id: file:///svn/phpbb/trunk@6159 89ea8834-ac86-4346-8a33-228a782c2dd0
re-introduce append_sid: old style continues to work, not a performance hog as it was in 2.0.x -> structure is different
apart from this, code cleanage, bug fixing, etc.
git-svn-id: file:///svn/phpbb/trunk@6015 89ea8834-ac86-4346-8a33-228a782c2dd0
