get and iter return None objects

[yoavnash]

When iterating a wrapper, some of the objects that are received are None

for c in wrapper.iter():
    print(c)

This is a buggy behavior since it fails some functionalities. For example, serialize_rdf_graph and iter(return_rel=True) who complain about those None objects.

It's unclear why it happens. Potential reasons:

• The deletion of objects using the function delete_cuds_object_recursively. (indeed the reason - see below)
• The expiration mechanism.

[yoavnash]

As additional info, when I run the following code:

print([(k,v) for k,v in wrapper._neighbors[common.hasA].items()])

I get:

[
    (UUID('e93e2d48-b271-4d52-9bfd-944089cde307'), []),
    (UUID('b16886ad-c208-45b1-b33e-c35f3ae5f7de'), [<OntologyClass knowledge.Software>]),
    (UUID('b7dcf244-75b8-453b-b8f4-5285e4649112'), []),
    (UUID('6befe33e-b5a7-464e-9edc-8b668449450c'), [<OntologyClass knowledge.User>]),
    (UUID('96b1b68f-a5a1-4d8d-b14e-cf1998267098'), []),
    (UUID('b9a377a0-e44f-44b0-b037-99f9de37bd4f'),[<OntologyClass knowledge.Expert>]),
    (UUID('94ea00a6-d509-4fe4-83aa-461f925f1a54'), [<OntologyClass knowledge.User>]),
    (UUID('2ee03b5e-1525-47ff-a3be-e134b053d3fd'), []),
    (UUID('81bfca1a-6384-4a76-8532-060dada56663'), [<OntologyClass knowledge.Software>]),
    (UUID('38778a7e-978b-4aac-a0ac-bce26b5a0019'), [<OntologyClass knowledge.Software>]),
    (UUID('a6bf20f0-9527-4413-a741-932cde3f8c77'), [<OntologyClass knowledge.Expert>])
]

Some elements are associated with empty lists, so when I do

c = wrapper.session.load(UUID('e93e2d48-b271-4d52-9bfd-944089cde307')).all()
print(c)

I see: [None]

[yoavnash]

After creating and deleting, it is the case that deleted items still appear like in the case above of 'e93e2d48-b271-4d52-9bfd-944089cde307'.

[kysrpex]

@yoavnash I am trying to reproduce this but not succeeding. Can you share some more details?

• To which kind of session did you connect the wrapper (Sqlite, Allegrograph, ...).
• Maybe share with me privately some of the data so I can test it.

[yoavnash]

I believe it's related to #626. Let's see if the problem persists after that is fixed.

[kysrpex]

Reopen if the problem persists.

[kysrpex]

I believe it's related to #626. Let's see if the problem persists after that is fixed.

@yoavnash See #626, it seems that nothing will change for unreachable CUDS, so this problem will persist.

[kysrpex]

Related to #638. Remember that the triples connecting the wrapper to the CUDS objects were not removed due to this bug. Those triples left behind by the wrapper in the added buffer makes it look like some CUDS objects are attached to the wrapper. However, when delete_cuds_object_recursively is used, no triples are left where the CUDS object is the subject (the object no longer exists). Therefore, it cannot be loaded from the backend and None is returned.

Installing the bugfix from PR #659 is not enough. The database is already contaminated with those triples, and has to be cleared before everything can work normally.

To close this issue, maybe some kind of "database cleaning tool" should be designed for existing ones.

[kysrpex]

To close this issue, maybe some kind of "database cleaning tool" should be designed for existing ones.

I do not think it makes sense to implement such a thing at this point, closing.