mysql - record and check state of local files #32
|
|
@ -2,15 +2,26 @@ var axios = require('axios');
|
|||
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 db = require("../models");
|
||||
|
||||
module.exports = {
|
||||
publishClaim: function(publishParams){
|
||||
|
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.
|
||||
publishClaim: function(publishParams, fileType){
|
||||
|
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 deferred = new Promise(function(resolve, reject){
|
||||
console.log(">> lbryApi >> publishClaim:", publishParams);
|
||||
axios.post('http://localhost:5279/lbryapi', {
|
||||
"method": "publish",
|
||||
"params": publishParams
|
||||
}).then(function (response) {
|
||||
console.log(">> 'publish' success");
|
||||
|
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(response.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.
|
||||
console.log(">> 'publish' 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.
|
||||
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: publishParams.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.
|
||||
claim_id: response.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.
|
||||
outpoint: response.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.
|
||||
file_name: "test",
|
||||
|
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_path: publishParams.filePath,
|
||||
|
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: fileType,
|
||||
|
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: 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:', 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.
|
||||
});
|
||||
|
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(response.data.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(error){
|
||||
console.log(">> 'publish' error");
|
||||
reject(error);
|
||||
|
|
@ -24,32 +35,33 @@ 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.
|
||||
axios.post('http://localhost:5279/lbryapi', {
|
||||
"method": "get",
|
||||
"params": { "uri": uri, "timeout": 20}
|
||||
}).then(function (getResponse) {
|
||||
|
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(">> 'get' success", 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.
|
||||
}).then(function (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.
|
||||
console.log(">> 'get' success", response.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.
|
||||
//check to make sure the daemon didn't just time out
|
||||
if (getResponse.data.result.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.
|
||||
reject(getResponse.data.result.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.
|
||||
if (response.data.result.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.
|
||||
reject(response.data.result.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.
|
||||
}
|
||||
/*
|
||||
note: put in a check to make sure we do not resolve until the download is actually complete (response.data.completed === true)
|
||||
*/
|
||||
// save a record of the file to the Files table
|
||||
db.File.create({
|
||||
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.
|
||||
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,
|
||||
|
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: response.data.result.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.
|
||||
claim_id: response.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.
|
||||
outpoint: response.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.
|
||||
file_name: response.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.
|
||||
file_path: response.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: response.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.
|
||||
nsfw: response.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){
|
||||
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.
|
||||
console.log('An error occurred when writing to the MySQL database:', 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.
|
||||
});
|
||||
// resolve the promise
|
||||
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){
|
||||
|
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(response.data.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(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(">> 'get' error");
|
||||
// reject the promise with an error message
|
||||
reject(getUriError);
|
||||
|
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.
|
||||
reject(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.
|
||||
return;
|
||||
});
|
||||
});
|
||||
|
|
|
|||
|
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.
|
||||
|
|
@ -90,21 +90,17 @@ 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.
|
||||
console.log(">> Asset was found locally");
|
||||
// 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.
|
||||
file_name: claim.dataValues.name,
|
||||
|
`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.
|
||||
download_path: claim.dataValues.path,
|
||||
|
`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.
|
||||
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.
|
||||
}
|
||||
|
`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.
|
||||
console.log("claim.dataValues", claim.dataValues);
|
||||
|
`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(claim.dataValues);
|
||||
|
`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 {
|
||||
// promise to get the chosen uri
|
||||
lbryApi.getClaim(freePublicClaimUri)
|
||||
.then(function(data){
|
||||
|
`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.
|
||||
.then(function(result){
|
||||
|
`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({
|
||||
file_name: data.result.file_name,
|
||||
|
`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.
|
||||
download_path: data.result.download_path,
|
||||
|
`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.
|
||||
content_type: data.result.metadata.stream.source.contentType
|
||||
|
`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: result.file_name,
|
||||
|
`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_path: result.download_path,
|
||||
|
`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_type: result.mime_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.
|
||||
});
|
||||
}).catch(function(error){
|
||||
reject(error)
|
||||
|
|
@ -129,11 +125,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.
|
||||
console.log(">> Asset was found locally");
|
||||
// if a record is found, return it
|
||||
if (claim){
|
||||
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,
|
||||
|
`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.
|
||||
download_path: claim.dataValues.path,
|
||||
|
`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.
|
||||
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.
|
||||
});
|
||||
|
`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(claim.dataValues);
|
||||
|
`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'
|
||||
|
|
@ -143,11 +135,11 @@ 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.
|
||||
if (isFreePublicClaim(resolvedUri.result[uri].claim)){
|
||||
// 'get' the claim
|
||||
lbryApi.getClaim(uri)
|
||||
.then(function(data){
|
||||
|
`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.
|
||||
.then(function(result){
|
||||
|
`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({
|
||||
file_name: data.result.file_name,
|
||||
|
`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.
|
||||
download_path: data.result.download_path,
|
||||
|
`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.
|
||||
content_type: data.result.metadata.stream.source.contentType
|
||||
|
`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: result.file_name,
|
||||
|
`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_path: result.download_path,
|
||||
|
`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_type: result.mime_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.
|
||||
});
|
||||
}).catch(function(error){
|
||||
reject(error)
|
||||
|
|
|
|||
|
`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.
|
||||
|
|
@ -51,21 +51,11 @@ module.exports = {
|
|||
// create the publish object
|
||||
var publishParams = createPublishParams(name, filePath, license, nsfw);
|
||||
// get a promise to publish
|
||||
lbryApi.publishClaim(publishParams)
|
||||
.then(function(data){
|
||||
lbryApi.publishClaim(publishParams, fileType)
|
||||
.then(function(result){
|
||||
visitor.event("Publish Route", "Publish Success", filePath).send();
|
||||
console.log("publish promise success. Tx info:", data)
|
||||
socket.emit("publish-complete", {name: name, result: data.result});
|
||||
db.File.create({
|
||||
name: name,
|
||||
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.');
|
||||
});
|
||||
console.log("publish promise success. Tx info:", result)
|
||||
socket.emit("publish-complete", {name: name, result: result});
|
||||
})
|
||||
.catch(function(error){
|
||||
visitor.event("Publish Route", "Publish Failure", filePath).send();
|
||||
|
|
|
|||
|
|
@ -4,13 +4,6 @@ module.exports = function(sequelize, DataTypes){
|
|||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
path: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
file_type: {
|
||||
type: DataTypes.STRING,
|
||||
},
|
||||
claim_id: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
|
|
@ -19,6 +12,17 @@ module.exports = function(sequelize, DataTypes){
|
|||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
file_name: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
file_path: {
|
||||
type: DataTypes.STRING,
|
||||
allowNull: false
|
||||
},
|
||||
file_type: {
|
||||
type: DataTypes.STRING,
|
||||
},
|
||||
nsfw: {
|
||||
type: DataTypes.BOOLEAN,
|
||||
allowNull: false,
|
||||
|
|
|
|||
|
|
@ -3,11 +3,11 @@ function serveFile(fileInfo, res){
|
|||
var options = {
|
||||
headers: {
|
||||
"X-Content-Type-Options": "nosniff",
|
||||
"Content-Type": fileInfo.content_type
|
||||
"Content-Type": fileInfo.file_type
|
||||
}
|
||||
};
|
||||
// adjust default options as needed
|
||||
switch (fileInfo.content_type){
|
||||
switch (fileInfo.file_type){
|
||||
case "image/jpeg":
|
||||
break;
|
||||
case "image/gif":
|
||||
|
|
@ -22,7 +22,7 @@ function serveFile(fileInfo, res){
|
|||
break;
|
||||
}
|
||||
// send file
|
||||
res.status(200).sendFile(fileInfo.download_path, options);
|
||||
res.status(200).sendFile(fileInfo.file_path, options);
|
||||
}
|
||||
|
||||
module.exports = function(app, routeHelpers, lbryHelpers, ua, googleAnalyticsId){
|
||||
|
|
@ -50,6 +50,7 @@ module.exports = function(app, routeHelpers, lbryHelpers, ua, googleAnalyticsId)
|
|||
console.log(">> GET request on /" + req.params.name);
|
||||
lbryHelpers.getClaimBasedOnNameOnly(req.params.name)
|
||||
.then(function(fileInfo){
|
||||
|
||||
console.log("/:name success.", fileInfo.file_name);
|
||||
serveFile(fileInfo, res);
|
||||
}).catch(function(error){
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
<div class="card-title">
|
||||
<div class="row">
|
||||
<div class="col-md-2">
|
||||
<img src="https://spee.ch/speech/900227fe5c778eb2a6424d923af806c669ea3a3c"/>
|
||||
<img src="/speech/900227fe5c778eb2a6424d923af806c669ea3a3c"/>
|
||||
</div>
|
||||
<div class="col-md-10 align-self-center">
|
||||
<h1><a class="white-text" href="/">Spee.ch</a></h1>
|
||||
|
|
|
|||
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.