Handle persistence with DB layer

[infusion]

Implement session storage of the server in either

• mongodb
• sqlite
• MySQL/PgSQL

[fredericosilva]

Hi, any those storages will require _selectAddress to be an asynchronous. How are you thinking about exposing this to the user? (parameter on server config?)

[infusion]

The previous idea is emitting an event, which can be handled by a storage solution to write down the information. On startup the data must be fetched asynchronously. Exposing parameters via the server config would be another option. What do you think is the better way?

[gregorybrzeski]

On startup the data must be fetched asynchronously.

What about data which changes while server is running ?

Maybe dynamic requests to backend with some type of local (in memory or persistent) cache ?

[infusion]

You mean administrative changes in the DB? Every change the server makes while running should affect the actual state and should simply be mirrored to the db layer. Handling administrative changes would require to query the db more frequently.

[fredericosilva]

Maybe, one could abstract those requirements in some kind of provider. That implements the selectAddress on an async fashion.

That will handle storage/backend scenarios.

Actual range/static/random may even be different provider implementations.

[fredericosilva]

Have a look on my fork, I've extracted the _getLease to have a single place where _selectAddress is called.

On _selectAddress I'm testing if a selectAddress exists on the config.

Any thoughts?

[infusion]

this.config('leaseTime');

shouldn't work in the callback. You should reference this to the outer scope. But I like the async nature, you introduced to the address selection. I wonder if we should make it more general to store any config, or at least the lease storage (aka _state).

[fredericosilva]

It works because I'm using an arrow function, 'this' is not changed.

Do you mean abstracting the access to _state with async get/set? and using it to implement different persistence layers?

[infusion]

Ahh, sorry. I only read the diff and missed the arrow function.

Yep exactly. What do you think about it?

[fredericosilva]

I like the ideia. If we have it like that, there is no need of exposing the selectAddress everything can be handled on the storage layer. Besides get/set what else do we need on that layer?

[infusion]

I think that's it and yep, it doesn't need to expose individual features like selectAddress this way :)

The remaining question is, how the storage interface is fed into the server. If it's a config option like:

dhcp.createServer({
...
storage: new dhcp.createMongoStorage('127.0.0.1', ...),
... 
});

or something else.

[gregorybrzeski]

Should it be called storage ? Maybe it should be called a provider.

It would be providers decision if to store it persistently, in memory or in any other way. Each provider can also make own decision if to provide response based on dynamic or static data.

[infusion]

You're right, Gregory. Provider might be a better name for it.

[SridharRamasami]

Hi, I am using this module and would like to add this functionality. However, I am not clear on the requirements per the conversation in this thread. Need some feedback and better instructions :-) Sridhar

[roccomuso]

Consider using something like keyv for the storage layer.

[infusion]

Oh, thanks for introducing keyv!