mecharex / logikaldb Goto Github PK

JCenter was added, because dokka depends on it, but we should remove it after they fully migrate to maven central

This is an epic size issue as it involves the creation and maintenance of these indexes

The database handler already supports a simple range read, but it doesn't cover every possibilities that FoundationDB offers

There is a bug in 0.3.0 which causes the murder mystery example to give back two results instead of one.
Most probably the problem is that the notEq(study, "Yolanda") constraint is not applied for some reason.

It's not a serialization issues as it also happens without the database.

Most probably there is a bug in the evaluation logic, because:

• and(notEq(study, "Yolanda"), murderer()) works
• and(murderer(), notEq(study, "Yolanda")) doesn't work

It shows that the problems happens when study is not available when notEq runs. (note: and reverses the execution order)

Interestingly it seems like and(murderer(), notEqDynamic(study, "Yolanda")) works.

It could be possible to transition into a static type system if we use heterogeneous map in the State.kt for storing the results.

It would be better to use database related words in the codebase instead of microKanren ones, because it would make it easier for the users and it would also make the explanations easier in the documentation.

Possible renamings:

• Goal = Constraint
• Variable = Field

Right now the constraint names are just represented by a simple toString() call which is not the most robust way to go about this.
Can we find a better and more official format?

It would improve usability if the library had a data mapper which can do the Data class <-> Field Entity conversion based on some annotations.

Field names should be unique per data class in order to avoid the name collision problem that we have now.

It should not try to be a relation mapper in the first iteration, because it makes the more task more complex if we also need to construct the implicit join operations. It should be part of a next ticket if we think it's worth doing.

It seems like we might need to add some annotation to the API code is it can be used by java applications.
Documentation about it: https://kotlinlang.org/docs/java-to-kotlin-interop.html#translation-of-type-nothing

Right now the and() function runs the best if:

• the first parameter constrains the most value and
• latter parameters filters out the later ones.

Unfortunately and becomes extremely slow if the most value is shifted to the last parameter.

This is also more of an investigation to see if we can make the and operator behave more generally where it doesn't matter the parameter order. This is possible as there was a talk and paper about how this can be achieved in the second minikanren workshop.

Maybe some performance improvements could be achieved switching from the immutable representation.
Would it cause any side effects?

This is a prerequisite task for the optimization task as there is no reason to do them without measuring the effectiveness,

Can we achieve a versioned system like unison?

An initial try was made to create this kind of system by adding the hashcode at the end of the function name, but this could break easily, because we only store the function names in the db and not the functions itself, which means that any update to the function results in a db, which contains deprecated constraint that can't be used anymore. Not to mention updating this kind of constraints also wasn't in place, so the system was removed.

This is an investigation if it's worth to replace the current registry solution with a more dynamic reflection based, which could make the system easier to use

Right now the logical operators are worked in a flipped way which means that the last parameter is evaluated first and first parameter evaluated last.

Does it makes sense to switch it back in the GoalConverter?
How can we achieve the switch back? Will it result in difficulties?

Right now variables are a global existence, so they can collide if they have the same name.
We should look into how we can make it easier to make the variable database or table specific.

This optimization about that if the user creates deep nested logical operations that we can simplify to simpler forms then we should do it. The best and maybe only place for this optimization is when we are converting the data representation to the functional one in the GoalConverter file.

For example: and(and(a=1,b=2),c=3, d=4) is the same as and(a=1,b=2,c=3,d=4)

Solving the #30 data mapper issue should make it possible to use field property references in constraints.
This would also improve the usability of the library, because we wouldn't need to worry about name collisions in the field names.

For example: eq(DataClass::Field, 136) should be possible with this feature.

Open questions:

• How will the new data mapper and the mapped data classes fit into the current constraint system?

It would be great if select could get the initial logikaldb reference from the logikaldb.read method, but it's not clear if there is a clean way to do it