streams/include/config.php

534 lines
14 KiB
PHP
Raw Normal View History

<?php
2011-08-10 08:19:27 +00:00
/**
* @file include/config.php
* @brief Arbitrary configuration storage.
2011-08-10 08:19:27 +00:00
*
* @note Please do not store booleans - convert to 0/1 integer values.
2011-08-10 08:19:27 +00:00
* The get_?config() functions return boolean false for keys that are unset,
2012-05-19 22:11:32 +00:00
* and this could lead to subtle bugs.
2011-08-10 08:19:27 +00:00
*
* Arrays get stored as serialize strings.
*
* @todo There are a few places in the code (such as the admin panel) where
* boolean configurations need to be fixed as of 10/08/2011.
*
* - <b>config</b> is used for hub specific configurations. It overrides the
* configurations from .htconfig file. The storage is of size TEXT.
* - <b>pconfig</b> is used for channel specific configurations and takes a
* <i>channel_id</i> as identifier. It stores for example which features are
* enabled per channel. The storage is of size MEDIUMTEXT.
* @code{.php} $var = get_pconfig(local_channel(), 'category', 'key');@endcode
* - <b>xconfig</b> is the same as pconfig, except that it uses <i>xchan</i> as
* an identifier. This is for example for people who do not have a local account.
* The storage is of size MEDIUMTEXT.
* @code{.php}
* $observer = $a->get_observer_hash();
* if ($observer) {
* $var = get_xconfig($observer, 'category', 'key');
* }@endcode
*
* - get_config() and set_config() can also be done through the command line tool
* @ref util/config.md "util/config"
* - get_pconfig() and set_pconfig() can also be done through the command line tool
* @ref util/pconfig.md "util/pconfig" and takes a channel_id as first argument.
*
2011-08-10 08:19:27 +00:00
*/
/**
* @brief Loads the hub's configuration from database to a cached storage.
*
* Retrieve a category ($family) of config variables from database to a cached
* storage in the global $a->config[$family].
*
* @param string $family
* The category of the configuration value
*/
function load_config($family) {
global $a;
if(! array_key_exists($family, $a->config))
$a->config[$family] = array();
if(! array_key_exists('config_loaded', $a->config[$family])) {
$r = q("SELECT * FROM config WHERE cat = '%s'", dbesc($family));
if($r !== false) {
if($r) {
foreach($r as $rr) {
$k = $rr['k'];
$a->config[$family][$k] = $rr['v'];
}
}
$a->config[$family]['config_loaded'] = true;
}
}
2013-02-26 23:49:37 +00:00
}
/**
* @brief Get a particular config variable given the category name ($family)
* and a key.
*
* Get a particular config variable from the given category ($family) and the
* $key from a cached storage in $a->config[$family]. If a key is found in the
* DB but does not exist in local config cache, pull it into the cache so we
* do not have to hit the DB again for this item.
*
* Returns false if not set.
*
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to query
* @return mixed Return value or false on error or if not set
*/
function get_config($family, $key) {
global $a;
if((! array_key_exists($family, $a->config)) || (! array_key_exists('config_loaded', $a->config[$family])))
load_config($family);
if(array_key_exists('config_loaded', $a->config[$family])) {
if(! array_key_exists($key, $a->config[$family])) {
return false;
}
return ((! is_array($a->config[$family][$key])) && (preg_match('|^a:[0-9]+:{.*}$|s', $a->config[$family][$key]))
? unserialize($a->config[$family][$key])
: $a->config[$family][$key]
);
}
return false;
2013-02-26 23:49:37 +00:00
}
/**
* @brief Returns a value directly from the database configuration storage.
*
* This function queries directly the database and bypasses the chached storage
* from get_config($family, $key).
*
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to query
* @return mixed
*/
function get_config_from_storage($family, $key) {
$ret = q("SELECT * FROM config WHERE cat = '%s' AND k = '%s' LIMIT 1",
2013-06-22 04:36:48 +00:00
dbesc($family),
dbesc($key)
);
return $ret;
}
/**
* @brief Sets a configuration value for the hub.
*
* Stores a config value ($value) in the category ($family) under the key ($key).
*
* @note Please do not store booleans - convert to 0/1 integer values!
*
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to set
* @param mixed $value
* The value to store in the configuration
* @return mixed
* Return the set value, or false if the database update failed
*/
function set_config($family, $key, $value) {
global $a;
// manage array value
$dbvalue = ((is_array($value)) ? serialize($value) : $value);
$dbvalue = ((is_bool($dbvalue)) ? intval($dbvalue) : $dbvalue);
if(get_config($family, $key) === false || (! get_config_from_storage($family, $key))) {
$ret = q("INSERT INTO config ( cat, k, v ) VALUES ( '%s', '%s', '%s' ) ",
dbesc($family),
dbesc($key),
dbesc($dbvalue)
);
if($ret) {
$a->config[$family][$key] = $value;
$ret = $value;
}
return $ret;
}
PostgreSQL support initial commit There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
2014-11-13 20:21:58 +00:00
$ret = q("UPDATE config SET v = '%s' WHERE cat = '%s' AND k = '%s'",
dbesc($dbvalue),
dbesc($family),
dbesc($key)
);
if($ret) {
$a->config[$family][$key] = $value;
$ret = $value;
}
return $ret;
2013-02-26 23:49:37 +00:00
}
/**
* @brief Deletes the given key from the hub's configuration database.
*
* Removes the configured value from the stored cache in $a->config[$family]
* and removes it from the database.
*
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to delete
* @return mixed
*/
function del_config($family, $key) {
global $a;
$ret = false;
if(array_key_exists($family, $a->config) && array_key_exists($key, $a->config[$family]))
unset($a->config[$family][$key]);
PostgreSQL support initial commit There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
2014-11-13 20:21:58 +00:00
$ret = q("DELETE FROM config WHERE cat = '%s' AND k = '%s'",
dbesc($family),
dbesc($key)
);
return $ret;
}
/**
* @brief Loads all configuration values of a channel into a cached storage.
*
* All configuration values of the given channel are stored in global cache
* which is available under the global variable $a->config[$uid].
*
* @param string $uid
* The channel_id
* @return void|false Nothing or false if $uid is false
*/
function load_pconfig($uid) {
global $a;
2013-06-18 09:06:16 +00:00
if($uid === false)
return false;
if(! array_key_exists($uid, $a->config))
$a->config[$uid] = array();
2014-11-24 23:36:11 +00:00
$r = q("SELECT * FROM pconfig WHERE uid = %d",
intval($uid)
);
if($r) {
foreach($r as $rr) {
$k = $rr['k'];
$c = $rr['cat'];
if(! array_key_exists($c, $a->config[$uid])) {
$a->config[$uid][$c] = array();
$a->config[$uid][$c]['config_loaded'] = true;
}
$a->config[$uid][$c][$k] = $rr['v'];
}
}
2013-02-26 23:49:37 +00:00
}
/**
* @brief Get a particular channel's config variable given the category name
* ($family) and a key.
*
* Get a particular channel's config value from the given category ($family)
* and the $key from a cached storage in $a->config[$uid].
*
* Returns false if not set.
*
* @param string $uid
* The channel_id
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to query
* @param boolean $instore (deprecated, without function)
* @return mixed Stored value or false if it does not exist
*/
function get_pconfig($uid, $family, $key, $instore = false) {
// logger('include/config.php: get_pconfig() deprecated instore param used', LOGGER_DEBUG);
global $a;
2013-06-18 09:06:16 +00:00
if($uid === false)
return false;
if(! array_key_exists($uid, $a->config))
load_pconfig($uid);
if((! array_key_exists($family, $a->config[$uid])) || (! array_key_exists($key, $a->config[$uid][$family])))
return false;
return ((! is_array($a->config[$uid][$family][$key])) && (preg_match('|^a:[0-9]+:{.*}$|s', $a->config[$uid][$family][$key]))
? unserialize($a->config[$uid][$family][$key])
: $a->config[$uid][$family][$key]
);
2013-02-26 23:49:37 +00:00
}
/**
* @brief Sets a configuration value for a channel.
*
* Stores a config value ($value) in the category ($family) under the key ($key)
* for the channel_id $uid.
*
* @note Please do not store booleans - convert to 0/1 integer values!
*
* @param string $uid
* The channel_id
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to set
* @param string $value
* The value to store
* @return mixed Stored $value or false
*/
function set_pconfig($uid, $family, $key, $value) {
global $a;
2011-12-19 17:01:38 +00:00
// manage array value
$dbvalue = ((is_array($value)) ? serialize($value) : $value);
$dbvalue = ((is_bool($dbvalue)) ? intval($dbvalue) : $dbvalue);
if(get_pconfig($uid, $family, $key) === false) {
if(! array_key_exists($uid, $a->config))
$a->config[$uid] = array();
if(! array_key_exists($family, $a->config[$uid]))
$a->config[$uid][$family] = array();
2011-12-19 17:01:38 +00:00
// keep a separate copy for all variables which were
// set in the life of this page. We need this to
// synchronise channel clones.
if(! array_key_exists('transient', $a->config[$uid]))
$a->config[$uid]['transient'] = array();
if(! array_key_exists($family, $a->config[$uid]['transient']))
$a->config[$uid]['transient'][$family] = array();
$a->config[$uid][$family][$key] = $value;
$a->config[$uid]['transient'][$family][$key] = $value;
$ret = q("INSERT INTO pconfig ( uid, cat, k, v ) VALUES ( %d, '%s', '%s', '%s' ) ",
intval($uid),
dbesc($family),
dbesc($key),
2011-12-19 17:01:38 +00:00
dbesc($dbvalue)
);
if($ret)
return $value;
return $ret;
}
PostgreSQL support initial commit There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
2014-11-13 20:21:58 +00:00
$ret = q("UPDATE pconfig SET v = '%s' WHERE uid = %d and cat = '%s' AND k = '%s'",
2011-12-19 17:01:38 +00:00
dbesc($dbvalue),
intval($uid),
dbesc($family),
dbesc($key)
);
// keep a separate copy for all variables which were
// set in the life of this page. We need this to
// synchronise channel clones.
if(! array_key_exists('transient', $a->config[$uid]))
$a->config[$uid]['transient'] = array();
if(! array_key_exists($family, $a->config[$uid]['transient']))
$a->config[$uid]['transient'][$family] = array();
$a->config[$uid][$family][$key] = $value;
$a->config[$uid]['transient'][$family][$key] = $value;
if($ret)
return $value;
return $ret;
2013-02-26 23:49:37 +00:00
}
/**
* @brief Deletes the given key from the channel's configuration.
*
* Removes the configured value from the stored cache in $a->config[$uid]
* and removes it from the database.
*
* @param string $uid
* The channel_id
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to delete
* @return mixed
*/
function del_pconfig($uid, $family, $key) {
global $a;
$ret = false;
if (x($a->config[$uid][$family], $key))
unset($a->config[$uid][$family][$key]);
PostgreSQL support initial commit There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
2014-11-13 20:21:58 +00:00
$ret = q("DELETE FROM pconfig WHERE uid = %d AND cat = '%s' AND k = '%s'",
intval($uid),
dbesc($family),
dbesc($key)
);
return $ret;
2013-02-26 23:49:37 +00:00
}
/**
* @brief Loads a full xchan's configuration into a cached storage.
*
* All configuration values of the given observer hash are stored in global
* cache which is available under the global variable $a->config[$xchan].
*
* @param string $xchan
* The observer's hash
* @return void|false Returns false if xchan is not set
*/
function load_xconfig($xchan) {
global $a;
2013-06-22 04:36:48 +00:00
if(! $xchan)
return false;
if(! array_key_exists($xchan, $a->config))
2013-06-22 04:36:48 +00:00
$a->config[$xchan] = array();
2014-11-24 23:36:11 +00:00
$r = q("SELECT * FROM xconfig WHERE xchan = '%s'",
dbesc($xchan)
);
2013-06-22 04:36:48 +00:00
if($r) {
foreach($r as $rr) {
$k = $rr['k'];
2013-06-22 04:36:48 +00:00
$c = $rr['cat'];
if(! array_key_exists($c, $a->config[$xchan])) {
2013-06-22 04:36:48 +00:00
$a->config[$xchan][$c] = array();
$a->config[$xchan][$c]['config_loaded'] = true;
}
$a->config[$xchan][$c][$k] = $rr['v'];
}
}
}
/**
* @brief Get a particular observer's config variable given the category
* name ($family) and a key.
*
* Get a particular observer's config value from the given category ($family)
* and the $key from a cached storage in $a->config[$xchan].
*
* Returns false if not set.
*
* @param string $xchan
* The observer's hash
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to query
* @return mixed Stored $value or false if it does not exist
*/
function get_xconfig($xchan, $family, $key) {
global $a;
2013-06-22 04:36:48 +00:00
if(! $xchan)
return false;
if(! array_key_exists($xchan, $a->config))
2013-06-22 04:36:48 +00:00
load_xconfig($xchan);
if((! array_key_exists($family, $a->config[$xchan])) || (! array_key_exists($key, $a->config[$xchan][$family])))
2013-06-22 04:36:48 +00:00
return false;
return ((! is_array($a->config[$xchan][$family][$key])) && (preg_match('|^a:[0-9]+:{.*}$|s', $a->config[$xchan][$family][$key]))
2013-06-22 04:36:48 +00:00
? unserialize($a->config[$xchan][$family][$key])
: $a->config[$xchan][$family][$key]
);
}
/**
* @brief Sets a configuration value for an observer.
*
* Stores a config value ($value) in the category ($family) under the key ($key)
* for the observer's $xchan hash.
*
* @note Please do not store booleans - convert to 0/1 integer values!
*
* @param string $xchan
* The observer's hash
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to set
* @param string $value
* The value to store
* @return mixed Stored $value or false
*/
function set_xconfig($xchan, $family, $key, $value) {
global $a;
// manage array value
2013-06-22 04:36:48 +00:00
$dbvalue = ((is_array($value)) ? serialize($value) : $value);
$dbvalue = ((is_bool($dbvalue)) ? intval($dbvalue) : $dbvalue);
if(get_xconfig($xchan, $family, $key) === false) {
if(! array_key_exists($xchan, $a->config))
2013-06-22 04:36:48 +00:00
$a->config[$xchan] = array();
if(! array_key_exists($family, $a->config[$xchan]))
2013-06-22 04:36:48 +00:00
$a->config[$xchan][$family] = array();
$a->config[$xchan][$family][$key] = $value;
2013-06-22 04:36:48 +00:00
$ret = q("INSERT INTO xconfig ( xchan, cat, k, v ) VALUES ( '%s', '%s', '%s', '%s' ) ",
dbesc($xchan),
dbesc($family),
dbesc($key),
dbesc($dbvalue)
);
2013-06-22 04:36:48 +00:00
if($ret)
return $value;
return $ret;
}
2013-06-22 04:36:48 +00:00
PostgreSQL support initial commit There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
2014-11-13 20:21:58 +00:00
$ret = q("UPDATE xconfig SET v = '%s' WHERE xchan = '%s' and cat = '%s' AND k = '%s'",
dbesc($dbvalue),
dbesc($xchan),
dbesc($family),
dbesc($key)
);
$a->config[$xchan][$family][$key] = $value;
if($ret)
return $value;
return $ret;
}
/**
* @brief Deletes the given key from the observer's config.
*
* Removes the configured value from the stored cache in $a->config[$xchan]
* and removes it from the database.
*
* @param string $xchan
* The observer's hash
* @param string $family
* The category of the configuration value
* @param string $key
* The configuration key to delete
* @return mixed
*/
function del_xconfig($xchan, $family, $key) {
global $a;
$ret = false;
if(x($a->config[$xchan][$family], $key))
unset($a->config[$xchan][$family][$key]);
2014-11-24 23:36:11 +00:00
$ret = q("DELETE FROM xconfig WHERE xchan = '%s' AND cat = '%s' AND k = '%s'",
dbesc($xchan),
dbesc($family),
dbesc($key)
);
return $ret;
}