electrodb - npm Package Versions

[3.4.1]

Fixed

• Issue #475; Fixes issue where some users reported errors exporting entities and/or types when using the CustomAttributeType function. They would receive an error similar to Exported variable '...' has or is using name 'OpaquePrimitiveSymbol' from external module "..." but cannot be named..

[3.4.0]

Added

• Issue #416; You can now use reverse indexes without the use of template.

[3.3.0]

• Fixed typing for "batchGet" where return type was not defined as a Promise in some cases.

Added

• Issue #416; You can now use reverse indexes on keys defined with a template. Previously, ElectroDB would throw if your entity definition used a pk field as an sk field (and vice versa) across two indexes. This constraint has been lifted if the impacted keys are defined with a template. Eventually I would like to allow this for indexes without the use of template, but until then, this change should help some users who have been impacted by this constraint.

[3.2.0]

Fixed

• When updating an item with a map attribute, if you attempt to set multiple keys that are identical after removing non-word characters (\w), Electro will generate the same expression attribute name for both keys. This occurs even though the original keys are different, leading to conflicts in the update operation. This update introduces a new change that ensures that each key will generate a unique expression attribute name. Contribution provided by @anatolzak via PR #461. Thank you for your contribution!

[2.15.1] - 2025-02-11

Hotfix

• Fixed typing for "batchGet" where return type was not defined as a Promise in some cases. This change is the 2.0.0 hotfix, the corresponding 3.0.0 change was introduced in 3.2.0.

[3.1.0]

Fixed

• Issue #464; When specifing return attributes on retrieval methods, ElectroDB would unexpectly return null or missing values if the options chosen resulted in an empty object being returned. This behavor could be confused with no results being found. ElectroDB now returns the empty object in these cases.

Added

• ElectroDB Error objects no contain a params() method. If your operation resulted in an error thrown by the DynamoDB client, you can call the params() method to get the compiled parameters sent to DynamoDB. This can be helpful for debugging. Note, that if the error was thrown prior to parameter creation (validation errors, invalid query errors, etc) then the params() method will return the value null.

[3.0.1]

Fixed

• The execution option { compare: "attributes" } used incorrect expression comparisons that impacted lte queries on indexes with a single composite key.

[3.0.0]

Changed

• ElectroDB is changing how it generates query parameters to give more control to users. Prior to v3, query operations that used the gt, lte, or between methods would incur additional post-processing, including additional filter expressions and some sort key hacks. The post-processing was an attempt to bridge an interface gap between attribute-level considerations and key-level considerations. Checkout the GitHub issue championed by @rcoundon and @PaulJNewell77 here to learn more. With v3, ElectroDB will not apply post-processing to queries of any type and abstains from adding implicit/erroneous filter expressions to queries by default. This change should provide additional control to users to achieve more advanced queries, but also introduces some additional complexity. There are many factors related to sorting and using comparison queries that are not intuitive, and the simplest way to mitigate this is by using additional filter expressions to ensure the items returned will match expectations. To ease migration and adoption, I have added a new execution option called compare; To recreate v2 functionality without further changes, use the execution option { compare: "v2" }. This value is marked as deprecated and will be removed at a later date, but should allow users to safely upgrade to v3 and experiment with the impact of this change on their existing data. The new compare option has other values that will continue to see support, however; to learn more about this new option, checkout Comparison Queries.
• The validate callback on attributes now expects a strict return type of boolean. Additionally, the semantic meaning of a boolean response has flipped. The callback should return true for "valid" values and false for "invalid" values. If your validation function throws an error, ElectroDB will still behave as it previously did in v2, by catching and wrapping the error.
• Providing the execution option limit on queries now only applies a Limit parameter to its request to DynamoDB. Previously, the limit option would cause ElectroDB to effectively "seek" DynamoDB until the limit was at least reached. The execution option count can be used in similar cases where limit was used, but performance may vary depending on your data and use case.

Removed

• The execution options includeKeys and raw were deprecated in version 2.0.0 and have now been removed in favor of the execution option data. To migrate from v2, use the options { data: "includeKeys" } and { data: "raw" } respectively.

Fixed

• Response typing and formatting logic for delete

[2.15.0] - 2024-09-19

Updated

• Updated @aws-sdk/lib-dynamodb dependency from pinned version 3.395.0 to latest release ^3.654.0. This impacts users using the v3 aws-sdk.
• Adds dependency @aws-sdk/util-dynamodb for unmarshalling functionality.

[2.14.3] - 2024-07-29

Fixed

• Raised via Issue #196 and Discussion 361; When using a clustered index with an empty composite array, update and patch methods would not correctly form the complete sort key value for the index. This would prevent impacted items from being queried via an Entity, though they could be queried via a collection on a Service. Thank you to github users @daniel7byte and @santiagomera for raising this issue!