Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core data types added #58

Open
8 tasks
saracalihan opened this issue Feb 1, 2023 · 1 comment
Open
8 tasks

Core data types added #58

saracalihan opened this issue Feb 1, 2023 · 1 comment
Labels
Milestone

Comments

@saracalihan
Copy link
Member

saracalihan commented Feb 1, 2023

Motivation

When we set out, we had planned to save objects with Redis only with hash type, but now I think that integrating other types of Redis into our system will make our project even stronger.

Currently, Model type using embeded hash function and flow. All Model functions and ModelInstance should be free from hashing and models should be written to return ModelInstance for each type.

All types has internal _write, _read functions and use it on that's business logic's. All models has to have common metronom datas like redisClient so i thing all models should extends on IModel interface and this interface include that datas.

// example usage
import { Hash, String, List } from 'metronom';

let user = Hash(schema, keyPrefix, modelOptions);
let token = String(key, 'value');
let ids = List(key);

user.isAdmin = true; // hSet
token.set('new-value'); // set
ids.push(102); // lPush
ids.unshift(205); // rPush
// ...

await user.save();
await token.save()
await ids.save();

await token.destroy()

Implementation

  • IModel interface(common function like find, getByPk, getAll, destroy ) added and Model abstructed from hash type
  • HashModel implemented
  • StringModel implemented
  • ListModel implemented
  • SetModel implemented
  • GeospatialIndexesModel implemented
  • BitmapModel implemented
  • BitFieldModel implemented

more detail for Redis types

@saracalihan saracalihan added the enhancement New feature or request label Feb 1, 2023
@saracalihan saracalihan modified the milestones: V2.0 , v3.0 Feb 1, 2023
@saracalihan saracalihan added the R&D label Feb 1, 2023
@saracalihan
Copy link
Member Author

saracalihan commented Feb 1, 2023

@beyzaerkan This is biggest technical and philosophical major change of metronom. Although we leave an object-based structure and support all types, our forest structure will have to change a little more.

For example, since it does not make sense to use functions such as Model.findAll in some types, we will have to remove them and add functions related to types, which I think will separate us a little from our initial output.

We can still stick to our core philosophy by adding static functions to models.

I'm curious about your thoughts as this is a big decision.

  • what do you think about it?
  • Should all types have their own ctor or they will be generated by the metronom object like metronom.define?
  • Do you have any idea for internal working of this?
  • Do you have any time for developing or are you ready for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant