platform/packages/redis
2024-10-12 18:45:27 -07:00
..
example Refactor: changing namespace, imports, re-branding 2024-10-12 18:45:27 -07:00
lib Refactor: changing namespace, imports, re-branding 2024-10-12 18:45:27 -07:00
test Refactor: changing namespace, imports, re-branding 2024-10-12 18:45:27 -07:00
.gitignore Add 'packages/redis/' from commit '929568c8660ecb4e6ddf1b6b616ab5591cb95419' 2020-02-15 18:29:13 -05:00
analysis_options.yaml Updated redis 2021-12-19 10:44:45 +08:00
AUTHORS.md Merged from sdk-2.12.x_nnbd 2021-06-20 20:37:20 +08:00
CHANGELOG.md Updated to support SDK 3.3.0 2024-06-23 12:09:26 +08:00
LICENSE Updated redis 2021-12-19 10:44:45 +08:00
pubspec.yaml Refactor: changing namespace, imports, re-branding 2024-10-12 18:45:27 -07:00
README.md Refactor: changing namespace, imports, re-branding 2024-10-12 18:45:27 -07:00

Protevus Redis

Pub Version (including pre-releases) Null Safety Discord License

Forked from angel_redis to support NNBD

Redis-enabled services for the Protevus framework. RedisService can be used alone, or as the backend of a CacheService, and thereby cache the results of calling an upstream database.

Installation

package:protevus_redis requires Protevus.

In your pubspec.yaml:

dependencies:
    protevus_framework: ^8.0.0
    protevus_redis: ^8.0.0

Usage

Pass an instance of RespCommandsTier2 (from package:resp_client) to the RedisService constructor. You can also pass an optional prefix, which is recommended if you are using protevus_redis for multiple logically-separate collections. Redis is a flat key-value store; by prefixing the keys used, protevus_redis can provide the experience of using separate stores, rather than a single node.

Without a prefix, there's a chance that different collections can overwrite one another's data.

Notes

  • Neither index, nor modify is atomic; each performs two separate queries.protevus_redis stores data as JSON strings, rather than as Redis hashes, so an update-in-place is impossible.
  • index uses Redis' KEYS functionality, so use it sparingly in production, if at all. In a larger database, it can quickly become a bottleneck.
  • remove uses MULTI+EXEC in a transaction.
  • Prefer using update, rather than modify. The former only performs one query, though it does overwrite the current contents for a given key.
  • When calling create, it's possible that you may already have an id in mind to insert into the store. For example, when caching another database, you'll preserve the ID or primary key of an item. protevus_redis heeds this. If no id is present, then an ID will be created via an INCR call.

Example

Also present at example/main.dart:

import 'package:protevus_redis/protevus_redis.dart';
import 'package:resp_client/resp_client.dart';
import 'package:resp_client/resp_commands.dart';
import 'package:resp_client/resp_server.dart';

main() async {
  var connection = await connectSocket('localhost');
  var client = RespClient(connection);
  var service = RedisService(RespCommandsTier2(client), prefix: 'example');

  // Create an object
  await service.create({'id': 'a', 'hello': 'world'});

  // Read it...
  var read = await service.read('a');
  print(read['hello']);

  // Delete it.
  await service.remove('a');

  // Close the connection.
  await connection.close();
}