CSV Import broken for new Dev versions vs Release Version 2.2.0

Configuration: Debian 12.12, MongoDB 7, Datagerry 2.2.0
Connection using HTTPS with Apache2 as reverse proxy

Test data CSV: # Testdata: cat company_2023-03-13.csv

public_id,active,text-19742,text-29607,text-11283,text-52606,text-36017
7,True,einsD,

Scenario:
Completely fresh cmdb database (with all types created from the initial type creation dialog)
No objects created by me

a) Create new Company object
b) Export Company
c) Import (update) the just created exported Company with only the content of the first textfield changed in the CSV (to see the difference)
d) Import (new) by removing the public id value in the CSV and changing the textfield
e) deleting all Company objects and create new from full CSV (i.e. WITH public id set)

  • Datagerry 2.2.0 (release version, file size 91035792 bytes):
    a-e without any error - OK
  • all developer version since at least 2025-03-21 till now
    a,b,c OK
    d → ERROR
    [2025-03-21 12:46:14][INFO ] — Executing connection check from: 127.0.0.1! (connection.py)
    [2025-03-21 12:48:20][ERROR ] — Exception on /import/object/ [POST] (app.py)
    Traceback (most recent call last):
    File “cmdb/models/object_model/cmdb_object.py”, line 137, in from_data
    AttributeError: ‘NoneType’ object has no attribute ‘get’

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “flask/app.py”, line 1473, in wsgi_app
File “flask/app.py”, line 882, in full_dispatch_request
File “flask_cors/extension.py”, line 178, in wrapped_function
File “flask/app.py”, line 880, in full_dispatch_request
File “flask/app.py”, line 865, in dispatch_request
File “cmdb/interface/route_utils.py”, line 174, in wrapper
File “cmdb/interface/route_utils.py”, line 161, in get_request_user
File “cmdb/interface/route_utils.py”, line 310, in _decorate
File “cmdb/interface/rest_api/routes/importer_routes/importer_object_routes.py”, line 269, in import_objects
File “cmdb/framework/importer/importers/csv_object_importer.py”, line 150, in start_import
File “cmdb/framework/importer/importers/object_importer.py”, line 134, in _import
File “cmdb/models/object_model/cmdb_object.py”, line 159, in from_data
cmdb.errors.models.cmdb_object.cmdb_object_errors.CmdbObjectInitFromDataError: ‘NoneType’ object has no attribute ‘get’

Scenario e) in the development version gives error:
[2025-03-21 12:52:29][ERROR ] — Exception on /import/object/ [POST] (app.py)
Traceback (most recent call last):
File “cmdb/models/object_model/cmdb_object.py”, line 137, in from_data
AttributeError: ‘NoneType’ object has no attribute ‘get’

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “flask/app.py”, line 1473, in wsgi_app
File “flask/app.py”, line 882, in full_dispatch_request
File “flask_cors/extension.py”, line 178, in wrapped_function
File “flask/app.py”, line 880, in full_dispatch_request
File “flask/app.py”, line 865, in dispatch_request
File “cmdb/interface/route_utils.py”, line 174, in wrapper
File “cmdb/interface/route_utils.py”, line 161, in get_request_user
File “cmdb/interface/route_utils.py”, line 310, in _decorate
File “cmdb/interface/rest_api/routes/importer_routes/importer_object_routes.py”, line 269, in import_objects
File “cmdb/framework/importer/importers/csv_object_importer.py”, line 150, in start_import
File “cmdb/framework/importer/importers/object_importer.py”, line 134, in _import
File “cmdb/models/object_model/cmdb_object.py”, line 159, in from_data
cmdb.errors.models.cmdb_object.cmdb_object_errors.CmdbObjectInitFromDataError: ‘NoneType’ object has no attribute ‘get’

IMPORTANT:
The most scary problem is that using this (corrupted) database gives import errors even if I revert back by using the release version (2.2.0).

Only solution for now is to delete the DB (mongosh --eval “use cmdb” --eval “db.dropDatabase()”) and let the version 2.2.0 recreate the DB.
BTW: running the Dev versions without a preexisting DB currently does not work - I will create a separate ticket for this.

In my opinion this is a very problematic show stopper for using the development versions.

I would like to use the dev versions (nice new features :slight_smile: ), but the above bug currently does not allow me to build my eval scenarios via CSV. I’m considering switching to using JSON exclusively for im/export for now to be able to test the dev versions.

Hi @cmdbeval1,
we will have a look at this.

BR Adnan

Hi @cmdbeval1,
the CSV import issue should be fixed we the latest dev version.

BR Adnan