| Age | Commit message (Collapse) | Author |
|---|
|
|
|
methods instance methods, create Update instances via DI, make Columns\Updater use instance methods instead of static, and add integration test for Columns\Updater.
|
|
show progress of update. Also remove CLI output code from CoreUpdater\Controller::runUpdaterAndExit.
|
|
errors caused by change to Updates.php and add some more functionality to ConsoleCommandTestCase base class.
|
|
Columns\Updater and document methods in Updater.
|
|
CoreUpdater static functions to core/Updater class, remove use of static methods in Updater, don't use static method setUpdater in ColumnsUpdater).
|
|
|
|
|
|
plugin even if the plugin is not enabled
|
|
|
|
code, few refactorings, all as part of our code cleanup strategy
|
|
|
|
User ID should be defined as dimension
|
|
dimension
|
|
(almost) any dimension. The filter can pivot reports by their subtable dimension and can also pivot by other dimensions (by using segments).
Notes:
- in the UI, only pivoting by subtable is supported
- change to CSV DataTable renderer so column names w/ commas & quotes can appear in text
- change to XML DataTable renderer so column names w/ invalid XML characters can be rendered (bit of an iffy change, XML format needs an overhaul I think)
- includes new config option 'pivot_by_filter_enable_fetch_by_segment'
- includes additions to component metadata classes (ie, Report/Dimension)
|
|
ComponentFactory utility class and reuse in Dimension to allow creating Dimension instances by human readable string IDs.
|
|
|
|
|
|
sure they are getting installed
|
|
|
|
c01d57bc17, this might work... basically the idea was ok but we should check for this only if the column actually already exists. If the column does not exist yet we need to make sure it will be installed
|
|
2.5.0-b1 the updater wanted to update all dimensions (meaning alter all columns in log_visit, link_action and conversion) to the same column type. This was happening because the system did not know those dimensions were already installed from a previous Piwik version. There was an update script that was supposed to tell Piwik those components are actually already installed since we only moved them from core to plugins but it cannot work as it is an update as well and therefore not executed before the actual update check. I tried many solutions to overcome this issue including reverting all the columns to the initial MySql Schema but even then there are problems as some plugins like DevicesDetection are not defined in MySql Schema but in the plugin. It is especially complicated since users might update from 2.4 to a future version where the column type of one of those dimension changes and we need to make sure to actually execute an alter update if one of those dimension changes. In such a case we cannot directly mark the component as successfully recorded. The conclusion was for me it is only possible to solve this problem by listing all dimensions that were moved from core to plugins including their version at that time hard coded...
|
|
gain another 100ms or more per page request. Otherwise we would have to load all dimensions on each request just to check for new version
|
|
persist static cache for tracker
|
|
|
|
|
|
|
|
|
|
mysql has gone away error
|
|
|
|
|
|
QUERY packet." errors on travis by splitting them into smaller alter tables. This is more or less the only difference to master branch where this problem does not occur
|
|
|
|
column in case the type changes making it super easy for developers, not sure if everything works already and need to xhprof it
|
|
added the platform should detect this and run an update script. also if a dimension suddenly handles new cases such as conversion it should automatically add a column to log_conversion after a user confirms. Have not tested update and/or installation yet
|
