Bug #201
/industry/catalog/blueprints/import/data/: DoesNotExist: CelestialObject matching query does not exist.
| Status: | Closed | Start date: | Jun 24, 2012 | |
|---|---|---|---|---|
| Priority: | Immediate | Due date: | ||
| Assignee: |  johnfoo |
% Done: | 100% |
|
| Category: | app-industry | Spent time: | 2.30 hours | |
| Target version: | 2.1.0 | |||
| Detected Version: | 2.0.5 | Python Version: | 2.6 |
Description
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-2.0.5.2.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-2.0.5.2.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.
History
#1
Updated by Drezil 11 months ago
maybe related to #199 as "in space"-data from POS didnt get pulled - but shouldn't error even then.
#2
Updated by johnfoo 11 months ago
- 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.
#3
Updated by johnfoo 11 months ago
- 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.
#4
Updated by diabeteman 11 months ago
- Target version changed from 32 to 2.1.0