Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#84 ] Add delete_atom method in the InMemoryDB adapter #89

Merged
merged 8 commits into from
Feb 2, 2024

Conversation

marcocapozzoli
Copy link
Collaborator

Resolves #84

if node:
atom_type = node['named_type']

named_type_exists = any(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to perform this single check, you are iterating on all nodes. I understand why you did it but you need to be very careful to not introduce this kind of inefficiency in the code as it may pass unnoticed. When it seems we are forced to introduce such type of performance penalty we need to discuss. In this case, for example, it's acceptable just to let go the unused types. The cost of having then is irrelevant and we can always have some type of periodical (or explicitly user-requested) cleanup tasks to clean up this kind of thing out of the AtomDB.

I've create a card to make sure we don't forget this (#90).

So you can remove this check and the code below which actually delete the atom type.

Copy link
Collaborator Author

@marcocapozzoli marcocapozzoli Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I understand and agree with you. We can implement a routine task to cleanup these atom_types in the future. I was aware of the performance and execution on all nodes and all links, but since we are on ramOnly I thought the atoms couldn't be too big. Actually thought I'd talk to you before implementing type removal. I imagine you would mention this point

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Understood. An additional comment, though: ramOnly is the adapter used by most of users in the MeTTa interpreter. It will be used to run the majority of the user's experiments. It's not just a buffer to store temporary info before moving it to a remote DAS server. So we must keep strict focus to make all operations as optimized as we can.

)

if not named_type_exists:
self._delete_atom_type(atom_type)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this (see comments above)


link_handle = atom['_id']

named_type_exists = any(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same comments I made for node type deletion applies here. But here it's even worst as you are iterating on all links (which are usually in larger number). Please delete this check.

)

if not named_type_exists:
self._delete_atom_type(atom['named_type'])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this (see comments above)

if len(pattern) > 0:
pattern.remove((link_document['_id'], tuple(targets_hash)))
if len(pattern) == 0:
self.db.patterns.pop(pattern_key, None)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong. The pattern key is still searchable even if there's no atom that matches it. We should leave the empty list.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I couldn't understand your point. After removing an item from a pattern_key I do another check and if this list is empty I completely remove pattern_key

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pattern holds a list of (handle, targets) that matched the pattern identified as pattern_key. In line 159 you check if this list became empty after removing the entry related to the link you are deleting (which you did in line 158). If this list is empty, you remove pattern_key out of self.db.patterns in line 160. This is wrong, you should keep the empty list there.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to keep this pattern empty? We talked about this case a few days ago and agreed that if the list is empty the patterns should be deleted

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take back my comment regarding the correctness of the code. It's correct, indeed, as any search for non-existent keys (either here in ramOnly and in redis-mongo) will return an empty list anyway. However it's still unnecessary. Perhaps I misunderstood the context when we discussed this before. Anyway I see no point in worrying about removing empty lists (in this and in all the other similar methods).

If you think we need to remove them, please provide details on why you think we should do it. If it's just to keep the tables clean of empty values (which would return [] if queried from non-existent keys anyway) I vote for just adding another "cleanup" task in the card #90

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

template_composite_type = self.db.templates.get(link_document['composite_type_hash'], [])
if len(template_composite_type) > 0:
template_composite_type.remove((link_document['_id'], tuple(targets_hash)))
if len(template_composite_type) == 0:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong. The template key is still searchable even if there's no atom that matches it. We should leave the empty list.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

if len(template_named_type) > 0:
template_named_type.remove((link_document['_id'], tuple(targets_hash)))
if len(template_named_type) == 0:
self.db.templates.pop(link_document['named_type_hash'], None)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong. The template key is still searchable even if there's no atom that matches it. We should leave the empty list.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

if len(handles) > 0:
handles.remove(link_handle)
if len(handles) == 0:
self.db.incoming_set.pop(atom_handle, None)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong. The key is still searchable even if there's no atom pointing to it. We should leave the empty list.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@marcocapozzoli marcocapozzoli merged commit 0dde042 into master Feb 2, 2024
1 check passed
@marcocapozzoli marcocapozzoli deleted the feature/issue-84-add-delete-atom branch February 2, 2024 19:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add delete_atom() method to InMemoryDB adapter
2 participants