drpandemic / masdb Goto Github PK

Add default signatures to Data.Map.select as we do in Masdb.Data.API.insert

After rereading our code, I realized that the return object of Masdb.Data.Map.insert/7 was inconsistent. Currently this function always returns {id, {...}}. But the second item could contain an error. This is not idiomatic of Elixir. If there's an error it should be the first or only returned value.

What's you opinion on that?

For the moment, the docker machines are not doing what they are suppose to do...
The build machine is suppose to only build the program and shutdown and the Prod machine is suppose to start a node in foreground.

It would be really usefull to be able to specify to the machine when we wan't to start the node in console mode.

We need to determine how the data will be stored.
There's a couple of question we have to answer:

• How do we validate insertion/update with the schema ?
• Do we accept NULL value. I.E. is it possible to insert partials record. ex: Student(id, name, tel) = (1,"JS", NULL) or Student(id, name, tel) = (1,"JS") ? (We will accept NULL values, but we won't sore them.)
• Is it required to store records contiguously in memory ?
  -- If yes, we could define a new datatype for each new table and have a single key per record ?
  -- If not, we could have a standard datatype for every table and have a key per record/column ?
  (We'll go with B))
• How should we store datatypes/should we enforce them? (The type will be stored only in the schema)
• Do we keep the history functionnality? (Yes)
  -- If yes, how do we store historical data? (We will keep the id of the last value + the timestamp of the insertion)
• How should we access the data?
• Do we want to control the data access (having users and writes) ? (No)
  -- I don't think so...
• How ids are going to be distributed/assigned to each record?

Ok, so we have https://github.com/DrPandemic/MasDB/blob/master/lib/masdb/distant_supervisor.ex to fetch remote PIDs. The goal of this module is to be able to spawn remote task to extract registered PIDs on that remote server.

A use case could be when the register want to update itself, it needs to contact a certain number of other register to be sure everyone agrees on the state. If we always work this way, it would be sub-optimal because it's a 2 way trip (get the PID and then call the genserver).

I see 2 possible simple solutions here. We could keep the current distant_supervisor concept and add a cache. This way, we wouldn't do a second query every time. But, managing a cache can be complicated.

The second solution could be to change/remove the distant_supervisor and add a way to directly call a remote genserver. Something like call(remote_node, fn, args). I think this could be done with protocols. Or, we could add directly other signature to our genserver functions. For example, if we have Masdb.Node.get_something(arg0) we could also add a function like Masdb.Node.get_something(arg0, remote_node) that would bridge the gap.

We need to define the initial way to interact with a process/cluster.

I think we could start with only the cli and add a config file if needed. I like the one from cockroach. So, I'll do something really similar to that.

My proposition:

• masdb start
• masdb client, this one could simply open an iex terminal. Maybe we don't need a command for that...
• massdb start --fileName=fileName, where the data will be stored. It will be useful when we have many node on the same box.
• massdb start --port=port --join=host:port, to expose a port and join a cluster.