chore: Changed tableName to memoryType as it is mapping to memories table in database

[asicarbon]

…the type field in the memories table in the DB. This improves code clarity as there were many places where a MemoryManager is created and took tableName and the code said this would act on a different database table, but in fact all of those lead to the memories table in the database, and tableName was just being mapped to type there, so memoryType is more appropriate name

Relates to:

No issue

Risks

Low

Background

What does this PR do?

This improves code clarity and understandability. Previously the code strongly implied that the MemoryManager would act on different tables in the underlying DB, whereas all instantiations of the MemoryManager actually write to the same table in the DB but write a string to the 'type' field to distinguish (and namespace) different types of memories. This PR renames 'tableName' as 'memoryType'

What kind of change is this?

Code improvement

Why are we doing this? Any context or related work?

As the code is evolving quickly, changes to improve understandability and semantically clear naming of variables and parameters will help us scale and improve overall developer productivity.

Documentation changes needed?

documentation changes are included

Testing

Tested changes.

Where should a reviewer start?

Discord username

ASI Carbon

[github-actions]

Hi @asicarbon! Welcome to the ai16z community. Thanks for submitting your first pull request; your efforts are helping us accelerate towards AGI. We'll review it shortly. You are now a ai16z contributor!

[odilitime]

This is going cause problems for the 70 or so PRs we have open. I'm not sure it's value is worth the cost. Though if we're going to do it, we better do it sooner than later.

[asicarbon]

always a trade off yes... a bit luckily i just did a quick search through the open PRs and looked at in the "files changed" for those containing "tableName"... was a manual check but only seemed to affect about 4-5 PRs out of all of them. I suspect this is because with many of the PRs their changes are well isolated in the code base.

On the value side of this change, I would say that this caused me quite a bit of confusion until I finally dug into the code and found that tableName was not in fact a reference to a table name at all. When I asked in the forum unfortunately nobody was able to answer me. Given the project is still so early... and more developer coming... the value of more rapidly understanding the system multiplied by all those developers reaching productivity a bit faster is real value. I know there is alot of interest in the memory system as well so as part of the core it should be as clear as possible IMHO.

[HashWarlock]

This is going cause problems for the 70 or so PRs we have open. I'm not sure it's value is worth the cost. Though if we're going to do it, we better do it sooner than later.

How do you think this will affect the v1 agents in production? Those agents that get an upgrade can be a headache to find out if their is not a public announcement on this type of change when it gets merged.

[odilitime]

I’m just looking for some additional input from Eliza devs before we make a decision. Thanks for the analysis asicarbon, it is helpful.

[asicarbon]

I’m just looking for some additional input from Eliza devs before we make a decision. Thanks for the analysis asicarbon, it is helpful.

sure thing!

[lalalune]

@odilitime I think this is correct