-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature resize images #27
base: main
Are you sure you want to change the base?
Changes from all commits
665807e
87da4b0
5d24f84
a803391
284c419
2164228
f5d859e
40f39de
e031e73
ebef3e2
e4ded14
9d450e4
7564967
3908691
3c46a1c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
{ | ||
} |
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
import { Knex } from 'knex'; | ||
|
||
import { Table } from '../db'; | ||
|
||
const tableConfig = | ||
{ | ||
name: Table.erc721Transfers, create: (table: Knex.CreateTableBuilder) => { | ||
table.string('id').primary(); | ||
table.datetime('createdAtTime', { precision: 3 }); | ||
table.bigint('createdAtEthereumBlockNumber'); | ||
table.string('from'); | ||
table.string('to'); | ||
table.string('contractAddress'); | ||
table.string('tokenId'); | ||
} | ||
}; | ||
|
||
export const up = async (knex: Knex) => { | ||
await knex.schema.createTable(tableConfig.name, tableConfig.create); | ||
await knex.raw(`GRANT SELECT ON "${Table.erc721Transfers}" TO ${process.env.POSTGRES_USERNAME_OPEN}`); | ||
}; | ||
|
||
exports.down = async (knex: Knex) => { | ||
await knex.schema.dropTable(tableConfig.name); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
import { Knex } from 'knex'; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i see u created this migration properly with timestamp - need to rename the other migrations to have timestamp too, as they're currently just in numeric order so could clash with timestamp ones - will do before merging this PR There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. haha ye i saw, was going to ask if i need to make mine the custom numbers |
||
|
||
import { Table } from '../db'; | ||
|
||
export const up = async (knex: Knex) => { | ||
console.log('Running create contracts bootstrap'); | ||
await knex.schema.createTable(Table.processedArtworks, (table: Knex.CreateTableBuilder) => { | ||
table.increments('id'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hmm not sure if should have an increment id? trackId should be unique could just be used as the primary key. we do just use this in other places - don't think there are any autoincrementing ids anywhere else. one of the motivation & requirements for no autoincrementing ids is to ensure that if we open source this and someone else runs it with their own endpoint, their DB looks the same and has the same ids as ours. With autoincrementing ids, this can't be guaranteed, for example consider each of the below scenarios:
2 weeks later, someone else runs the thing:
the other person will end up with a different order of IDs, since our initial run had the monday noizd tracks mixed in. the current design has a nice property across all tables where the order of all operations in the pipeline is basically irrelevant and 2 different people running it will eventually converge on to mostly the same state and same db contents (with some minor buggy exceptions probably) so this also means that if we add a peer-to-peer network at some point in future where different nodes share and sync their data, it will be easy to do so if everyone is on the same page about ordering, as there will be no need for debate or consensus between nodes on ordering. (this motivation/requirement may not be that important tbh, could be a bit overkill/premature optimization, but given we've got this property already and it's easy to preserve for now, i think worth preserving) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ye i figured this would be a problem based on the other code that i read through :). was being a bit lazy. i cant use trackId since there are multiple images per track but i could follow your format that makes ids deterministic There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ye i mean it may make sense to actually process images from the nft directly rather than from the track, and use the nft id too. would need to handle the case where multiple nfts all have the same image tho. |
||
table.string('error'); | ||
table.string('size'); | ||
table.string('trackId'); | ||
table.string('cid'); | ||
}); | ||
await knex.raw(`GRANT SELECT ON "${Table.processedArtworks}" TO ${process.env.POSTGRES_USERNAME_OPEN}`); | ||
}; | ||
|
||
exports.down = async (knex: Knex) => { | ||
await knex.schema.dropTable(Table.processedArtworks); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i decided to use this just because its was easier for me, happy to use non sugar client, i see you mostly interact with axios