volse-hubzilla.git - Volse Hubzilla -- soft fork of main Hubzilla core for Volse

	Commit message (Collapse)	Author	Age	Files	Lines
...
*	Update issues on postgres	zotlabs	2018-04-29	3	-3/+3
\|
*	fix any misconfigured channel permission limits	zotlabs	2018-04-20	1	-0/+26
\|
*	missing update file in the previous update commit	zotlabs	2018-04-16	1	-0/+26
\|
*	OAuth2 integration	zotlabs	2018-04-03	1	-0/+78
\|
*	fix syntax error in postgres update	Mario	2018-03-08	1	-3/+3
\|
*	federated polls: GNU-Social requires us to preserve the original order of ↵	zotlabs	2018-03-07	1	-0/+26
\| \| \| \|	the poll answers for use in making a vote, unlike diaspora (which selects by guid) and activitypub (which selects by non-localisable text).
*	federated polls: add poll_author which will be necessary for Diaspora federation	zotlabs	2018-03-06	1	-0/+26
\|
*	update DB update 1205 to mitigate	Mario Vavti	2018-03-02	1	-0/+11
\| \| \| \|	ERROR 1069 (42000): Too many keys specified; max 64 keys allowed
*	db update to drop index resource_type. we have uid_resource_type now.	Mario Vavti	2018-03-02	1	-0/+24
\|
*	typo	Mario Vavti	2018-02-28	1	-1/+1
\|
*	missed one index in the last update	Mario Vavti	2018-02-28	1	-0/+24
\|
*	another DB upgrade to address some long running maintenance queries	Mario Vavti	2018-02-26	1	-0/+27
\|
*	fix issues with DB update 1204	Mario Vavti	2018-02-23	1	-3/+3
\|
*	provide DB compatibility for poll and voting implementations across several ↵	zotlabs	2018-02-22	1	-0/+34
\| \| \| \|	platforms
*	missing file	Mario Vavti	2018-02-20	1	-0/+29
\|
*	updates 1201 and 1200 should return success for postgres. notifications: ↵	Mario Vavti	2018-02-19	3	-8/+16
\| \| \| \|	remove class show and session storage entry when we mark all notifications seen
*	backport update 1201 to the new update system and move dummy update to 1202	Mario Vavti	2018-02-19	2	-5/+28
\|
*	refactor of the DB update system. Updates are now stored individually in ↵	zotlabs	2018-02-16	202	-0/+4496
	Zotlabs/Update/_nnnn.php and are objects; so only the pending updates need to be loaded and executed rather than all historical updates. There is one single number (DB_UPDATE_VERSION) representing the current version and it is EQUAL TO the last known update. A dummy update _1201 was created to address the difference in counting behaviour; it will be executed on the next change of DB_UPDATE_VERSION as well as the next update. The database config values are also loaded from disk on every update immediately before setting the update lock in order to reduce timing conflicts and race conditions.