-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pull request for issues 11 and 13. #19
base: master
Are you sure you want to change the base?
Conversation
…sers to make schema upgrades.
Working on issue 13 next. Let me know if you have any coding preferences, so I can implement them on my next pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Overall, this is really solid. Let me know what you think of the comments and we can go from there.
src/BlazorDB/wwwroot/blazorDB.js
Outdated
window.blazorDB.getTable(item.dbName, item.storeName).then(table => { | ||
table.toCollection().count().then((result) => { | ||
dotnetReference.invokeMethodAsync('BlazorDBCallback', transaction, false, 'getMinIndex succeeded'); | ||
resolve(result == 0 ? "Table empty" : 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about returning a -1
instead of Table Empty
?
The concern is just getting it the same type return for if/else
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented.
src/BlazorDB/wwwroot/blazorDB.js
Outdated
window.blazorDB.getTable(item.dbName, item.storeName).then(table => { | ||
table.toCollection().count().then((result) => { | ||
dotnetReference.invokeMethodAsync('BlazorDBCallback', transaction, false, 'getMaxIndex succeeded'); | ||
resolve(result > 0 ? (result - 1) : "Table empty"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about returning a -1
instead of Table Empty
?
The concern is just getting it the same type return for if/else
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented.
// Assumption. Only one schema update per version update | ||
// Will allow multiple updates after proof of concept | ||
// This function purposefully DOES NOT return a promise. This is because .upgrade() DOES NOT return a promise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noting this assumption.
I'm okay for a round 1 draft too, it's just one update per version and we just error if storeSchemeUpgrades.length > 1
to let the user know.
// Assumption. Only one schema update per version update | ||
// Will allow multiple updates after proof of concept | ||
// This function purposefully DOES NOT return a promise. This is because .upgrade() DOES NOT return a promise. | ||
upgradeDbSchema: function (db, stores, dbStore) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great add, only thing I'd look at doing is handle some possible user errors. Some that come to mind
- Column in row doesn't exist
- If the column for the row returns a
null
value how doessplit
or other actions perform?
Just looking to see how we support these cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working this now. I'll provide more feedback later tonight or tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, all errors are caught in the catch at line 63 in blazorDB.js. So if I try to split a row that does not exist, the following error is logged to the console.
We need to make these errors more specific and useful. I think the best way to do that is to create an error handling function and call it inside of upgradeDbSchema(). The error handling function will look at the schemaUpdate.upgradeAction property and perform different checks to ensure all properties contain useable data. If a property does not contain useful data, I will throw an error message relative to that property. For instance, if the schemaUpdate.upgradeAction == 'split' and the columnsToPerformActionOn property is null or does not exist in the store I will throw an error that states, "columnsToPerformActionOn is null" or "columnsToPerformActionOn does not exist in store".
This thrown error will be caught at line 63 in blazorDB.js and logged to the console. The upgrade error will not effect the db instance since the version.upgrade() creates a database transaction. Dexie.js will simply use the last version of the database. So whatever the current version is.
What do you think? I think the custom error handling function will be the only way to return useful error messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change of plans after testing. I decided to add verifyStoreSchemaUpgrades() to the if logic that determines if upgradeDbSchema() is called. See below.
This ensures we will not attempt to perform a database upgrade via upgradeDbSchema() with incorrect parameters. I like this change because it ensures that the opening of a database will not be affected by any error that occurs in upgradeDbSchema().
verifyStoreSchemaUpgrade() will return false if the give storeSchemaUpgrade parameters do not match the given schemaUpdate.upgradeAction. See below for an example.
I will finish verifyStoreSchemaUpgrades() tomorrow then commit my code. Let me know if you have any feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach. Nice change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet. Let me know if you see anything else I need to change on my end.
MinimumVisualStudioVersion = 10.0.40219.1 | ||
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "BlazorDB", "src\BlazorDB\BlazorDB.csproj", "{D0180843-D92A-44B7-9893-F2450415F208}" | ||
EndProject | ||
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "BlazorDB.Example", "example\BlazorDB.Example\BlazorDB.Example.csproj", "{155CD782-6CEF-4115-9A04-1864A2CDFC90}" | ||
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "BlazorDB.Example", "BlazorDB.Example\BlazorDB.Example.csproj", "{A47C9FCB-70BC-4B16-B5BB-68C8F6B1012E}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious why we are moving this out of the example
folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was unintentional. Will be fixed on next commit.
Additions: