mysql - record and check state of local files #32
|
|
@ -26,11 +26,10 @@ module.exports = {
|
|||
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
"params": { "uri": uri, "timeout": 20}
|
||||
}).then(function (getResponse) {
|
||||
console.log(">> 'get' success", getResponse.data);
|
||||
//check to make sure the daemon didn't just time out (or otherwise send an error that appears to be a success response)
|
||||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
//check to make sure the daemon didn't just time out
|
||||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
if (getResponse.data.result.error){
|
||||
reject(getResponse.data.result.error);
|
||||
}
|
||||
// resolve the promise with the download path for the claim we got
|
||||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
/*
|
||||
note: put in a check to make sure we do not resolve until the download is actually complete (response.data.completed === true)
|
||||
|
This section can be simplified by avoiding repetition of This section can be simplified by avoiding repetition of `response.data.result`.
(unnecessary return) (unnecessary return)
✔️ :heavy_check_mark:
✔️ :heavy_check_mark:
|
||||
*/
|
||||
|
|
@ -40,12 +39,13 @@ module.exports = {
|
|||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
path: getResponse.data.result.download_path,
|
||||
file_type: getResponse.data.result.mime_type,
|
||||
claim_id: getResponse.data.result.claim_id,
|
||||
outpoint: getResponse.data.result.outpoint,
|
||||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
nsfw: getResponse.data.result.metadata.stream.metadata.nsfw,
|
||||
}).catch(function(error){
|
||||
console.log('an error occurred when writing to the MySQL database. Check the logs.');
|
||||
});
|
||||
// resolve the promise
|
||||
resolve(getResponse.data); //to do: return the result
|
||||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
resolve(getResponse.data);
|
||||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
}).catch(function(getUriError){
|
||||
console.log(">> 'get' error");
|
||||
// reject the promise with an error message
|
||||
|
|
|
|||
|
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
It might be a good idea to declare an extremely simple error logging class or function that simply calls Not a blocking suggestion. It might be a good idea to declare an extremely simple error logging class or function that simply calls `console.log` internally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.
Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO. Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.
good point. will aim to address on next update. good point. will aim to address on next update.
agreed. will wait and address this with the next big update which will be focused on logging. agreed. will wait and address this with the next big update which will be focused on logging.
|
||||
|
|
@ -61,6 +61,7 @@ module.exports = {
|
|||
path: filePath,
|
||||
file_type: fileType,
|
||||
claim_id: data.result.claim_id,
|
||||
outpoint: getResponse.data.result.outpoint,
|
||||
nsfw: nsfw,
|
||||
}).catch(function(error){
|
||||
console.log('an error occurred when writing to the MySQL database. Check the logs.');
|
||||
|
|
|
|||
|
|
@ -1,27 +1,31 @@
|
|||
module.exports = function(sequelize, DataTypes){
|
||||
var File = sequelize.define("File", {
|
||||
name: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false,
|
||||
validate: {
|
||||
len: [1]
|
||||
}
|
||||
},
|
||||
path: {
|
||||
type: DataTypes.STRING
|
||||
},
|
||||
file_type: {
|
||||
type: DataTypes.STRING
|
||||
},
|
||||
claim_id: {
|
||||
type: DataTypes.STRING
|
||||
},
|
||||
nsfw: {
|
||||
type: DataTypes.BOOLEAN,
|
||||
defaultValue: false
|
||||
}
|
||||
}, {
|
||||
var File = sequelize.define("File", {
|
||||
name: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
path: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
file_type: {
|
||||
type: DataTypes.STRING,
|
||||
},
|
||||
claim_id: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
outpoint: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
nsfw: {
|
||||
type: DataTypes.BOOLEAN,
|
||||
allowNull: false,
|
||||
defaultValue: false
|
||||
}
|
||||
}, {
|
||||
freezeTableName: true
|
||||
});
|
||||
return File;
|
||||
return File;
|
||||
}
|
||||
It might be a good idea to declare an extremely simple error logging class or function that simply calls
console.loginternally. That way when you want to replace it later with more sophisticated logging, you can do so easily, rather than needing to track down all the log calls.Not a blocking suggestion.
Writing all paths as relative from the root project folder rather than relative from the current file will make for later easier refactoring IMO.