Difference between revisions of "PartKeepr 0.1 issues"
From PartKeepr Wiki
(+Some comments) |
|||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | Findings of partkeepr 0.1 on Ubuntu 10.4 LTS, PostgreSQL 8.4.9 | + | == 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?) | ||
| + | ** This should be fixed with v0.1.1 --[[User:Felicitus|Felicitus]] 08:23, 29 December 2011 (CET) | ||
| − | * When renaming categories, the contained parts categorypath is not updated leading to wrong grouping in the Parts List window | + | * 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) |
| − | (there may be other consequences, too) | ||
| − | + | * '''Only applies to PostgreSQL 8.x''': View->Statistics->Summary gives an SQL Exception: | |
| − | * View->Statistics->Summary gives an SQL Exception: | + | <pre> |
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: | ||
| − | 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} | + | #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} | ||
| + | </pre> | ||
| − | * The attachted Footprint | + | * 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? |
| − | download them. | + | ** This is a bug which should be fixed with v0.1.1. The path to the data directory was set wrong using the web installer; the footprints should belong into the directory data/files/FootprintAttachment/. You might want to extract the filename of a footprint from the database to find out it's name, then move all the files from that wrong directory to the correct directory. The additional footprints on demo.partkeepr.org come from our RaumZeitLabor installation, so we actually did enter them manually. --[[User:Felicitus|Felicitus]] 08:23, 29 December 2011 (CET) |
| − | BTW: Why are there so many more footprints on the | ||
| + | * 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... :-) | To be continued... :-) | ||
Latest revision as of 08:23, 29 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?)
- This should be fixed with v0.1.1 --Felicitus 08:23, 29 December 2011 (CET)
- 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?
- This is a bug which should be fixed with v0.1.1. The path to the data directory was set wrong using the web installer; the footprints should belong into the directory data/files/FootprintAttachment/. You might want to extract the filename of a footprint from the database to find out it's name, then move all the files from that wrong directory to the correct directory. The additional footprints on demo.partkeepr.org come from our RaumZeitLabor installation, so we actually did enter them manually. --Felicitus 08:23, 29 December 2011 (CET)
- 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... :-)
