Give name to a rule (and may be an id??)

@CacheControl Is there a way we can give names to our rules? So for example:

let volumeRule = new Rule({
  **name: myVolumeRule  //----- Note the name here** 
  conditions: {
    all: [{
      fact: 'volume',
      operator: 'greaterThanInclusive',
      value: 100
    }]
  },
  event: {  // define the event to fire when the conditions evaluate truthy
    type: 'fouledOut',
    params: {
      message: 'Player has fouled out!'
    }
  }
  ,
  priority: 100
});

So the reason for this is that when you are writing 100s of rules, you may want to give them name to identify which rule you are talking about. Also, if we are saving them into a database, we can save them in rows and identified by their names. Its helpful when you are managing a large number of rules.

[murraybauer]

thanks @CacheControl appreciate the heads up and suburb work on rule results! The example looks to be a perfect fit. Will implement beta2 to test in the next few days and let you know.

[CacheControl]

@slmmm You’re 100% correct! This project is coming up on a year old, and I think I’m starting to forget why certain design decisions were made. Thanks for keeping me honest! Also, I’d like to take this opportunity to thank you for your input on this project - it is very much appreciated.

@arsalans I’ve persisted rules in a database with this project before, so perhaps I can provide some guidance. Assuming you’re using a relational database, I think it’s best to think about each rule as being a column, rather than a row. So after calling rule.toJSON(), you might take that value and store it in a definition column. Our table schema looked something like the following:

CREATE TABLE `rules` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(256) NOT NULL,
  `definition` TEXT NOT NULL,  # this is where rule.toJSON() would go
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

This allows you to add things like foreign keys to other resources (is the rule “owned” by something?), and provide columns for other metadata you find useful.

If you’re going the NoSQL approach, you’d probably want to follow the same conceptual pattern; simply nest the rule.toJSON() results into a dedicated property of whatever resource you’re persisting.

Finally, I see the responsibility of enforcing things like rule uniqueness as being outside the scope of this library - as modeled above, this is something most database technologies (or if working on the front end, libraries like lodash) do very well already, and I’d prefer to keep json-rules-engine lightweight and un-opinionated in this regard; a thing that runs rules and spits out results.

Does this help and/or address your concerns?