Releases: SierraSoftworks/Iridium
Version 8.0.0-alpha.3
This release adds a number of fixes for v2.4.1 of TypeScript as well as a regression test for #91. More notably, it also removes Bluebird as a dependency, allowing you to use Iridium with native promises (#95). You can still use Bluebird if you wish by importing it as a poly-fill, but this is now at the discretion of the user.
Version 8.0.0-alpha.2
This release fixes an issue with the Cache interface which was raised in #86 as part of the v8.0.0-alpha.1 release.
Version 8.0.0-alpha.1
This release removes the [name: string]: any
indexer type from the Iridium.Instance
class. This means that you will be forced, when working with TypeScript, to sub-class Iridium.Instance
for any custom models (already the best practice and most commonly used approach).
It also adds support for TypeScript 2.4.1's stricter generic checks, which has resulted in a few interfaces being slightly changed. These changes should have no affect on your code, however as they are changes to the public API, this has resulted in a major version bump.
Version 7.2.5
This release addresses an issue in the diff calculator which is showcased in #83, specifically when you are computing a diff on an array of documents where properties of some change while other documents are removed. This would result in only the removal operation being generated and would leave the changed documents in their original state.
const original = { array: [
{ x: 1, y: 1 },
{ x: 2, y: 2 }
]}
const current = { array: [
{ x: 1, y: 2 }
]}
const expectedDiff = {
"$set": {
"array": [
{ x: 1, y: 2 }
]
}
}
const brokenDiff = {
"$pull": {
"array": { x: 2, y: 2 }
}
}
Thank you to @fduplessisduplessis for the comprehensive reproduction case which enabled us to identify and resolve the issue.
Version 7.2.4
This version fixes #82, a particularly painful bug that had taken a while to track down. It is finally fixed thanks to the hard work of @fduplessisduplessis and EMSSConsulting, thanks to everyone involved in getting that addressed.
npm install iridium@7.2.4
Changes
Version 7.2.1
This patch release updates the mapReduce implementation to reduce the dependency on TypeScript type checking for reliable operation of the methods - instead using runtime checks to ensure that expected values are present. This should not only make them safer for pure JavaScript users but also simplify implementation constraints for TypeScript users. Thanks to @RagibHasin for #78 which addresses these issues.
Version 7.2.0
This release adds support for MongoDB's mapReduce
operation thanks to a brilliant PR by @RagibHasin. It supports both inline mapReduce and reducing into a typed Iridium collection. It also includes a number of improvements to Iridum's documentation and some regression tests to help avoid situations like we saw in #73.
Using MapReduce
Inline Reduce
Inline reductions are great for once-off operations where you do not wish to persist the results to a collection. It allows you to provide a map
and reduce
function and will return the resulting documents that leave the reduce
function.
interface MySourceDoc {
_id: string;
group_key: string;
value: number;
}
@Iridium.Collection("source")
class MySourceModel extends Iridium.Instance<MySourceDoc, MySourceModel> {
_id: string;
group_key: string;
value: number;
}
const core = new Iridium.Core("mongodb://localhost:27017")
await core.connect()
const source = new Iridium.Model<MySourceDoc, MySourceModel>(core, MySourceModel);
const result = await source.mapReduce({
map: function() {
emit(this.group_key, this.value);
},
reduce: function(key, values) {
return Array.sum(values);
}
}, { out: "inline" });
result.forEach(item => {
console.log(`group '${item._id}': ${item.value}`);
});
Reduce into a Collection
In situations where you require more control over the documents you receive from mapReduce
(performing transforms etc) you can use the @Iridium.MapReduce
decorator function on an instance class and provide that to the mapReduce
method call. This will allow you to retroactively access the results of the mapReduce
operation in the specified @Iridium.Collection
.
interface MySourceDoc {
_id: string;
group_key: string;
value: number;
}
@Iridium.Collection("source")
class MySourceModel extends Iridium.Instance<MySourceDoc, MySourceModel> {
_id: string;
group_key: string;
value: number;
}
interface MyReducedDoc {
_id: string;
value: number;
}
@Iridium.Collection("reduced")
@Iridium.MapReduce<MySourceDoc, string, number>(function() {
emit(this.group_key, this.value);
}, function(key, values) {
return Array.sum(values);
})
class MyReducedModel extends Iridium.Instance<MyReducedDoc, MyReducedModel> {
_id: string;
value: number;
}
const core = new Iridium.Core("mongodb://localhost:27017")
await core.connect()
const source = new Iridium.Model<MySourceDoc, MySourceModel>(core, MySourceModel);
const reduced = new Iridium.Model<MyReduceDoc, MyReduceModel>(core, MyReduceModel);
await source.mapReduce(reduced, { out: "replace" })
await reduced.find().forEach(item => {
console.log(`group '${item._id}': ${item.value}`);
});
Version 7.1.3
This release updates Iridium's Cursor implementation to ensure it is compatible with the latest MongoDB.Cursor type as raised in #68.
Version 7.1.2
This release fixes the behavior of the Model.insert
and Model.create
methods when the { upsert: true }
option is provided and documents do not include an _id
field. Previously, documents would be "upserted" with { _id: null }
leading to issues.
As of this release, documents will be upserted using { _id: { $exists: false } }
as the default upsert condition when an _id
is not provided - resolving this problem.
Please be aware that using { upsert: true }
imparts a significant performance penalty on bulk inserts and should be avoided in situations where you are working with a large number of documents. The better approach is to split your document set into documents with _id
s and those without, using { upsert: true }
only for those in the former set and using { upsert: false }
for the rest.
Version 7.1.0
This release includes a large amount of refactoring to ensure compatibility with TypeScript 2.1 and enabling of the noImplicitAny
build flag (which is disabled by default).
In addition to that, the requirements on what type of promise is allowed for Core.onConnecting
and Core.onConnected
has been relaxed thanks to the work of @aikoven.
We've also put in some work to reducing code quality warnings on BitHound which should also make it easier to follow portions of our codebase.
The final change, and reason for the minor version bump, is the inclusion of Iridium's Changes
type in our external API. This type neatly enforces the MongoDB changes object, allowing you to strongly type aspects of your code which generate these.