mysql - record and check state of local files #32
|
|
@ -1,4 +1,5 @@
|
|||
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.
|
||||
var axios = require('axios');
|
||||
var db = require("../models");
|
||||
|
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.
|
||||
|
||||
module.exports = {
|
||||
publishClaim: function(publishParams){
|
||||
|
|
@ -33,7 +34,18 @@ 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.
|
||||
/*
|
||||
|
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:
|
||||
note: put in a check to make sure we do not resolve until the download is actually complete (response.data.completed === true)
|
||||
*/
|
||||
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.
|
||||
// save a record of the file to the Files table
|
||||
|
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.
|
||||
db.File.create({
|
||||
|
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.
|
||||
name: getResponse.data.result.file_name,
|
||||
|
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,
|
||||
|
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.
|
||||
file_type: getResponse.data.result.mime_type,
|
||||
|
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.
|
||||
claim_id: getResponse.data.result.claim_id,
|
||||
|
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,
|
||||
|
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(error){
|
||||
|
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.
|
||||
console.log('an error occurred when writing to the MySQL database. Check the logs.');
|
||||
|
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.
|
||||
// resolve the promise
|
||||
|
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); //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.
|
||||
}).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.
|
||||
|
|
@ -87,7 +87,7 @@ module.exports = {
|
|||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
// check to see if the file is available locally
|
||||
db.File.findOne({where: { claim_id: claimId }})
|
||||
.then(function(claim){
|
||||
console.log("asset found locally >>", claim)
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
console.log(">> Asset was found locally");
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
// if a record is found, return it
|
||||
if (claim){
|
||||
var fileInfo = {
|
||||
|
|
@ -126,15 +126,14 @@ module.exports = {
|
|||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
// check locally for the claim
|
||||
db.File.findOne({where: { claim_id: claimId }})
|
||||
.then(function(claim){
|
||||
console.log("asset found locally >>", claim)
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
console.log(">> Asset was found locally");
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
// if a record is found, return it
|
||||
if (claim){
|
||||
var fileInfo = {
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
resolve({
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
file_name: claim.dataValues.name,
|
||||
download_path: claim.dataValues.path,
|
||||
content_type: claim.dataValues.file_type
|
||||
}
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
resolve(fileInfo);
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
});
|
||||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
// ... otherwise use daemon to retrieve it
|
||||
} else {
|
||||
// get the claim info via 'resolve'
|
||||
|
|
|
|||
|
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
`lbryHelpers.js` sounds like and sort of looks like the kind of file that is on track to accumulate a lot of functions and become a mess. Worth looking at the typical patterns for unique or business-level modal functions in this framework.
may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods. may have gone a little overboard, but I did a big reorganize to address this because I agree itt was getting disorganized. This hopefully will lay the groundwork for better organization going forward. Separated out true controller functions from helper methods.
|
||||
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.