Divide by zero error when migrating database schema on upgrade install initial setup

[DoctorOctagonapus]

I'm upgrading PartKeepr from v0.1.9 to v0.82 on Ubuntu 14.04.4, I've been using this as my basic guide: https://wiki.partkeepr.org/wiki/PartKeepr_on_Debian_%22Jessie%22 and have made it as far as running the initial setup, step "Setup (1/2)". Testing for database connectivity and setting up the database schema run successfully, but migrating the database schema returns the error "Invalid response from server". I'm pasting the error details below:

Invalid Response from server

Warning: Division by zero

500 Internal Server Error - ContextErrorException

Stack Trace

1. in src/PartKeepr/PartBundle/Entity/Part.php at line 841 -

   1.         $lastPosEntryQuant = $stockLevel->getStockLevel();
      

   2.         $lastPosEntryPrice = $stockLevel->getPrice();
      

   3.         $totalPartStockPrice += $lastPosEntryPrice \* ($lastPosEntryQuant + $negativeStock);
      

   4.         $price = $totalPartStockPrice / $sum;
      

   5.     }
      

   6.     else {
      

   7.         if ($sum <= 0) {
      

2. at ErrorHandler ->handleError ('2', 'Division by zero', '/var/www/partkeepr-0.82/src/PartKeepr/PartBundle/Entity/Part.php', '841', array('sum' => '0', 'price' => '0', 'totalPartStockPrice' => '0', 'lastPosEntryQuant' => '3', 'lastPosEntryPrice' => null, 'negativeStock' => '-3', 'stockLevel' => object(StockEntry)))
   in src/PartKeepr/PartBundle/Entity/Part.php at line 841
3. at Part ->recomputeStockLevels ()
   in src/PartKeepr/CoreBundle/DoctrineMigrations/Version20151002183125.php at line 26 +
4. at Version20151002183125 ->up (object(Generated2e01a7af5663aaa6f05dbe19bed007fa))
   in vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Version.php at line 290 +
5. at Version ->execute ('up', false, false)
   in vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Migration.php at line 176 +
6. at Migration ->migrate ('20160103145302')
   in src/PartKeepr/SetupBundle/Controller/SchemaMigrationSetupController.php at line 34 +
7. at SchemaMigrationSetupController ->intMigrateSchemaAction (object(Request))
8. at call_user_func_array (array(object(SchemaMigrationSetupController), 'intMigrateSchemaAction'), array(object(Request)))
   in app/bootstrap.php.cache at line 3192 +
9. at HttpKernel ->handleRaw (object(Request), '1')
   in app/bootstrap.php.cache at line 3154 +
10. at HttpKernel ->handle (object(Request), '1', true)
    in app/bootstrap.php.cache at line 3305 +
11. at ContainerAwareHttpKernel ->handle (object(Request), '1', true)
    in app/bootstrap.php.cache at line 2498 +
12. at Kernel ->handle (object(Request))
    in src/PartKeepr/SetupBundle/Controller/SetupBaseController.php at line 38 +
13. at SetupBaseController ->handleRequest (object(Request), '/setup/_int_migrate_schema')
    in src/PartKeepr/SetupBundle/Controller/SchemaMigrationSetupController.php at line 54 +
14. at SchemaMigrationSetupController ->migrateSchemaAction (object(Request))
15. at call_user_func_array (array(object(SchemaMigrationSetupController), 'migrateSchemaAction'), array(object(Request)))
    in app/bootstrap.php.cache at line 3192 +
16. at HttpKernel ->handleRaw (object(Request), '1')
    in app/bootstrap.php.cache at line 3154 +
17. at HttpKernel ->handle (object(Request), '1', true)
    in app/bootstrap.php.cache at line 3305 +
18. at ContainerAwareHttpKernel ->handle (object(Request), '1', true)
    in app/bootstrap.php.cache at line 2498 +
19. at Kernel ->handle (object(Request))
    in web/setup.php at line 13 +

Logs -

Stack Trace (Plain Text) +

By the look of it there's something in the old database that it's failing on, even though it's the same data that v0.1.9 was happy with. Any ideas on how to fix this?

[Drachenkaetzchen]

@tinutac can you have a look at this?

[Drachenkaetzchen]

@DoctorOctagonapus can you provide the column data of the database record with id 841? It's inside the table 'Part`

[tinutac]

@FELICITUS I'll take a look this weekend. Quite busy at work :(. I have to update to 0.82 myself.
@DoctorOctagonapus a column data would help indeed.

[DoctorOctagonapus]

@FELICITUS @tinutac My parts table only goes up to id=375. Querying for 841 just returns empty set.

I thought the 841 was a line reference in Part.php, am I wrong in thinking that?

[Drachenkaetzchen]

@DoctorOctagonapus you're right, I didn't pay enough attention yesterday ;) Would it be possible that you send us the dump of your Part table?

[DoctorOctagonapus]

@FELICITUS Sure thing here you go.

part.zip

[Drachenkaetzchen]

@DoctorOctagonapus On second thought, a complete dump for sake of easiness to reproduce would probably be better. For confidentially reasons you can also send the dump to info at partkeepr dot com.

[DoctorOctagonapus]

@FELICITUS I've e-mailed it over to you.

[Drachenkaetzchen]

@tinutac the issue occurs when the sum of additions and removals for a single Part equals 0 and the last entry was an addition. In the dump sent by @DoctorOctagonapus the additions and removals looked like the attachment.

[tinutac]

@FELICITUS Thanks for the update. That shouldn't have been an issue. I'm checking it now. So those are all the entries for that part? Normally the total stock is checked before the division.
Another issue. On the line 841 we have: $negativeStock = 0;. So no division there. Divisions are on lines: 852: $price = $totalPartStockPrice / $sum;, 864: $price = $totalPartStockPrice / $sum;, and 868: $price = $totalPartStockPrice / $sum;
That rather looks like an older version of Part.php.

[Drachenkaetzchen]

@tinutac yes, that are all entries for the Part which is causing the issue. The division occurs in line 852. If $sum in line 845 is 0, it gets divided by zero in line 852.

[tinutac]

Oh, crap. You're right. I'll make a fix.The $sum is indeed not checked before the division on line 852.

[Drachenkaetzchen]

Oh that occasion, can you take care of the indentation? PartKeepr uses PSR1/2, you can fix it using php-cs-fixer

[tinutac]

I thought it was fixed. Something wrong with Eclipse. I'll check that also.

[Drachenkaetzchen]

I will test the patch tomorrow and report back

[tinutac]

@FELICITUS I hope the formatting is ok now. I've tested it on my test database here and it seems ok. I've tried to imagine all possible scenarios. Hope none missed this time.
@DoctorOctagonapus sorry for the delay, @FELICITUS will give you further instructions.

[Drachenkaetzchen]

I just tested the patch and it works fine with the dump from @DoctorOctagonapus. I will close the issue now, a new release should be out today or tomorrow.