search

soartech / jsoar

Pure Java implementation of the Soar cognitive architecture.
http://soartech.github.com/jsoar/
BSD 3-Clause "New" or "Revised" License
53 stars 19 forks source link

Feature Request: Ability to use different database. #139

Open Polytehnitis opened 1 year ago

Polytehnitis commented 1 year ago

Can you please make jsoar to connect to the database through a single file API? This way one could connect a separate database or a different one if they don't want to use sqlite.

marinier commented 1 year ago

This is sort of already supported. The class AbstractSoarDatabase gets its various SQL statements from files in jsoar-core/src/main/resources/org/jsoar/kernel/[epmem or smem], so equivalent statements for other databases can be added.

In fact, long ago we had statements for MySql and postgres for smem, but they were 10x slower than sqlite (because they had to be accessed over the network as opposed to in-process), so no one ever used them. When we had to make significant updates to smem, we removed them rather than maintain them. (See commit 751fe389bf859f7e1c5734beb763614768200df5.)

I don't believe epmem ever supported multiple databases. If you'd like to contribute a pull request to support a different database for either or both of epmem and smem, I'd be happy to accept it.

Polytehnitis commented 1 year ago

The database that I am considering is TypeDB. It is a Hypergraph database, which makes it different than SQL type databases and it also has its own inference engine which I would like to capitalise. I would like to do a pull request however I haven't done anything like this before . I am also not really good at programming. Would you be able to help?

marinier commented 1 year ago

Unfortunately I don't have the resources to help support a major feature like this. Every once in a while I end up getting a chunk of time from my company (SoarTech) to work on JSoar in some significant way, but it's unlikely they would want to support this particular feature unless there was an obvious benefit to doing so. Part of the issue is that the original C++ Soar (from which this is ported) uses sqlite, so deviating from that would make future porting much more difficult. I'm happy to answer questions and such, but I can't provide the kind of support you're asking for.

Polytehnitis commented 1 year ago

I believe that there is a significant benefit to having a port like this. First of, since the database has its own inference engine, you as the developers of Soar will only have to focus on Soar production rules that all agents should have in common. Secondly, since it is a hypergraph database, it will provide to its users a visual representation on how the brain of their agents look like . Fourthly this database provides graph analysis tools based on graph theory that will provide the users with better insight on how their agents work. And finally, having a separate database would allow many users or devises to run the same agent. Please have a look at this database that I am recommending. Its like its was made for Soar.