I think maybe I have fundamentally misunderstood how indexes work... My understanding was that I could have something like
export const heroSchemaLiteral = {
title: "hero schema",
description: "describes a simple hero",
version: 0,
primaryKey: "name",
type: "object",
properties: {
name: {
type: "string",
maxLength: 100,
},
hp: { type: "number" },
maxHP: { type: "number" },
color: {
type: "string",
maxLength: 100,
},
},
required: ["name", "color"],
indexes: ["color"],
} as const; const toto = await db?.heroes
.find({
selector: { color: { $eq: "red" } },
index: "color",
})
.exec();But this just always gives "{error: 'unknown_error', message: 'Could not find that index or could not use that index for the query'}".
I tried various other options, like index: ["color"] and index: ["color", "name"] but it always gives the same error. I am getting this will 12.2 and 12.3.
At least with 12.3, this appears to only error out with pouchdb and not dexie, though I don't know whether dexie is actually using the index or not.
25 replies
multipleOf on the number type fields has an issue in typescript. The typescript type is number but the validate plugin uses is-my-json-valid, and the method used to validate this in their code is isMultipleOf. The issue with that is that when you pass in a number to that method, it does the following multipleOf.toString().split('.').pop().length to get the length of the remainder to validate a number coming in. Unfortunately, number.toString() in JS when the number is smaller than 0.00001 moves to using exponents, meaning 0.0000001.toString() == "1e-7", which is obviously going to make everything fail erroneously. So!- Is this a bug that
is-my-json-validshould fix? - Is this an issue with the typescript type and we should allow
number | stringand put a note in the docs to say you MUST use a string if themultipleOfis less than 0.00001? - Something else?
3 replies
bufferTime in rxjs return an empty array each time? The snippet below always returns empty array. this.db.userFolderTree.$.pipe(
bufferTime(1000)
).subscribe((changeEvent) => {
console.log("userFolderTree changeEvent", changeEvent);
console.dir(changeEvent);
});
Hello All, please, I'm a new to Rxdb.. Using it with Typescript / React.. I'm trying to save an attachment as
const attachment = await hero.putAttachment(
{
id: "cat.jpg", // (string) name of the attachment like 'cat.jpg'
data: 'some blob data', // (string|Blob|Buffer) data of the attachment
type: "text/plain", // (string) type of the attachment-data like 'image/jpeg'
},
false // (boolean, optional, default=true) skipIfSame:If true and attachment already exists with same data, the write will be skipped
);I'm getting an error : Uncaught (in promise) TypeError: hero.putAttachment is not a function
6 replies
Hi all. So I have just been testing 12.4.1 regarding the query planner and (at least) dexie storage. Consider a collection definitions with a string field graph (amongst others) that has an index (in addition to a pk id). (and in the examples const graph = '那么';)
Here is what I have found:
In 12.4.1
db.definitions.findOne({ selector: { graph: { $eq: graph } }, })will use the["graph", "id"]index withstartKey: ['那么', -Infinity]andendKeys: ['那么', ''], and also did so with 12.3.2 (and tbh maybe earlier also), with or without a manually specifiedindex: "graph"on the query. Queries get returned in the 2-5ms range.In 12.3.2
db.definitions.findOne().where("graph").eq(graph)will use the (pointless here)["id"]index withstartKeys: [-Infinity]andendKeys: ['']. Performance is horribly slow, queries get returned in the 20-40 SECOND range.In 12.4.1
db.definitions.findOne().where("graph").eq(graph)will use the["graph", "id"]index withstartKey: [-Infinity, -Infinity]andendKeys: ['', '']. Performance is very notably better than 12.3.2 but still horrible, in the 5-15 SECOND range.
Ok, now I can't promise there won't be bugs (it's still beta, after all) but if anyone is using pouch+idb and is synching to a graphql endpoint, then I can heartily suggest giving the dexie storage a go with the latest (12.4.1+) rxdb. You may need to tweak some queries (see my previous post) but... WOW! Particularly when compiled in production mode, I am seeing MASSIVE speed-ups across the board, anywhere from 2x to 10x. It was a bit clunky and slow before but I accepted it because I am using react-admin, and have a data driver that first goes through a proxy to a service worker and then all data access is done via the single service worker process in a second data access layer. But now with dexie and 12.4.1 (with a couple of tweaks) everything is now lightning fast, and I am now not regretting the extra couple of layers of complexity at all (which makes having web + chrome extension much easier to manage with a single codebase).
Thanks again Mr Meyer for all your awesome work!
db.inventory.find( { "size.uom": "in" } )? Link
await db.remove() with 12.4.1 and dexie storage will return a list of collections that have supposedly been deleted but that physically the indexeddb databases are still there, only emptied? I am pretty sure they used to get actually deleted with pouchdb-idb and rxdb 11.
May i know what's the query method to empty out a collection?
I thought myCollection.bulkUpsert([]) would delete all contents but it simply ignores it by looking at the source code of the method.
What i actually intend to do is simply replace the contents of the current collection, is the viable method simply remove all contents and insert the documents in the collection? Maybe i'm not aware of it, but is there a replace method?
9 replies
{
limit: line,
skip: page === 1 ? 0 : (page - 1) * line,
sort: [{ published_at: "desc" }, { id: "desc" }],
index: ["id", "published_at"],
}{
indexes: ["id", "published_at", ["id", "published_at"]],
} {
"rxdb": "^12.1.0",
"rxjs": "^7.5.5",
}
rxdbMeta on documents to work and of course they dont have it. I tried to create a migration and add the property myself but then I have a crash saying that I am trying to add extra properties to the schema. I am not sure this is the proper way to migrate to new version, any idea ?
4 replies
1 reply
@mbret This is known. You can add the _meta field or use the migrateRxDBV11ToV12 plugin, but that is in the premium package.
migrateRxDBV11ToV12 A plugin that migrates data from any RxDB v11 storage to a new RxDB v12 database. Use this when you upgrade from RxDB 11->12 and you have to keep your database state.
It basically takes all documents from the old storage, adds missing _meta and inserts them into the new storage