/industry/catalog/blueprints/import/data/: DoesNotExist: CelestialObject matching query does not exist.
|Status:||Closed||Start date:||Jun 24, 2012|
|Category:||app-industry||Spent time:||2.30 hours|
|Detected Version:||2.0.5||Python Version:||2.6|
Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/django/core/handlers/base.py", line 111, in +get_response response = callback(request, *callback_args, **callback_kwargs) File "/usr/local/lib/python2.6/dist-packages/ecm-220.127.116.11.dev-py2.6.egg/ecm/views/decorators.py", line 104, in +_wrapped_view return view_function(request, *args, **kwargs) File +"/usr/local/lib/python2.6/dist-packages/ecm-18.104.22.168.dev-py2.6.egg/ecm/plugins/industry/views/catalog/import_blueprints +.py", line 109, in blueprints_data location_name = celestial_objects.get(itemID=bp.closest_object_id).itemName File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/django/db/models/query.py", line 366, in get % self.model._meta.object_name) DoesNotExist: CelestialObject matching query does not exist.
maybe related to #199 as "in space"-data from POS didnt get pulled - but shouldn't error even then.
- Status changed from New to In Progress
- Assignee changed from diabeteman to johnfoo
- Priority changed from Normal to Immediate
- Target version set to 32
reproduced trying to display 100 items per page, POS data got pulled, so unrelated. most probably related to the new ccp dump integration.
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
solved. couple of issue there:
the BPO import process is dependent on the location of the BPs. if you have assets in conquerable outposts, they're not part of the datadump, and the task updating the location of assets relies on the task updating the outposts. the outpost task was screwed by the recent integration of the ccp datadump directly into ecm's own database, started mumbling incoherent stuff, and stopped working. however, while we DO handle priorities in the scheduling process, so each task can work after its various parents and find its data where it expects it, we do not currently manage a parent failing, and the scheduler happily proceeds with launching the children tasks, which will, of course, fail for lack of available data. subsequently, when trying to import BPOs, not having a stationID, ecm looked for a closest_celestial_id and found the default of 0 (#System) because we don't care about closest_celestial_id if we are not in a POS, so we never update it. having no celestial named #System, the exception manager raised a second CelestialObject.DoesNotExists which was never handled, and django raises a nice 500.
running the outpost update task, THEN the assets update tasks IF the outpost task succeeded, will fix the situation after tonights commit.