Difference between revisions of "PartKeepr 0.1 issues"
| Line 12: | Line 12: | ||
(there may be other consequences, too) | (there may be other consequences, too) | ||
| − | * View->Statistics->Summary gives an SQL Exception: | + | * '''Only applies to PostgreSQL 8.x''': View->Statistics->Summary gives an SQL Exception: |
SQLSTATE[42803]: Grouping error: 7 ERROR: column "p1_.name" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: ...LECT SUM(p0_.stockLevel) AS sclr0, p1_.id AS id1, p1_.name A... ^ | SQLSTATE[42803]: Grouping error: 7 ERROR: column "p1_.name" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: ...LECT SUM(p0_.stockLevel) AS sclr0, p1_.id AS id1, p1_.name A... ^ | ||
Backtrace: | Backtrace: | ||
Revision as of 19:30, 28 December 2011
Findings of partkeepr 0.1 on Ubuntu 10.4 LTS, PostgreSQL 8.4.9
Author: apex
Just collecting, lets see which one will make it to the bug tracker
- FIXED: Installer lockup during Database Setup, see https://github.com/partkeepr/PartKeepr/issues/114
- After Setting up Partkeeper, no parts are shown in the Parts List even after adding some. Plain SQL shows that the part table
actually contains the expected entries. The parts are shown only after a restart of the browser (session/cache issue?)
- When renaming categories, the contained parts categorypath is not updated leading to wrong grouping in the Parts List window
(there may be other consequences, too)
- Only applies to PostgreSQL 8.x: View->Statistics->Summary gives an SQL Exception:
SQLSTATE[42803]: Grouping error: 7 ERROR: column "p1_.name" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: ...LECT SUM(p0_.stockLevel) AS sclr0, p1_.id AS id1, p1_.name A... ^ Backtrace: 0 /usr/share/php/Doctrine/DBAL/Connection.php(618): PDO->query('SELECT SUM(p0_....') #1 /usr/share/php/Doctrine/ORM/Query/Exec/SingleSelectExecutor.php(46): Doctrine\DBAL\Connection->executeQuery('SELECT SUM(p0_....', Array, Array) #2 /usr/share/php/Doctrine/ORM/Query.php(249): Doctrine\ORM\Query\Exec\SingleSelectExecutor->execute(Object(Doctrine\DBAL\Connection), Array, Array) #3 /usr/share/php/Doctrine/ORM/AbstractQuery.php(607): Doctrine\ORM\Query->_doExecute() #4 /usr/share/php/Doctrine/ORM/AbstractQuery.php(413): Doctrine\ORM\AbstractQuery->execute(Array, 1) #5 /var/www/partkeepr/src/backend/de/RaumZeitLabor/PartKeepr/PartUnit/PartUnitManager.php(103): Doctrine\ORM\AbstractQuery->getResult() #6 /var/www/partkeepr/src/backend/de/RaumZeitLabor/PartKeepr/Statistic/StatisticService.php(22): de\RaumZeitLabor\PartKeepr\PartUnit\PartUnitManager->getUnitCounts() #7 /var/www/partkeepr/src/backend/de/RaumZeitLabor/PartKeepr/Service/ServiceManager.php(79): de\RaumZeitLabor\PartKeepr\Statistic\StatisticService->getCurrentStats() #8 /var/www/partkeepr/frontend/rest.php(54): de\RaumZeitLabor\PartKeepr\Service\ServiceManager::call() #9 {main}
- The attachted Footprint PDFs added the installer result in 0 byte files when trying to
download them. This does not happen to files attached by myself. BTW: Why are there so many more footprints on the PartKeepr demo website?
- It seems that innermost part categries can be deleted although they contain parts. The
foreign key constraints on the database tables prevents PartKeepr of actually doing so but for the user the category seem to be gone (until he pushes the refresh button... :-))
To be continued... :-)
