#aaronpkbecause they'd still clobber each other cause they read the post contents into memory in order to manipulate the properties
#aaronpkalso i'm using this storage wrapper which allows storing files on things that might not be the filesystem so i don't actually have access to filesystem locking https://laravel.com/docs/5.2/filesystem
#voxpelliright, yeah, that would complicate things
#aaronpkeither way, the problem is when two processes load the post into RAM, manipulate it there, then try to write it back to disk
#aaronpkbreaking up the data into separate units (either by using different columns or tables in an RDBMS, or using different files for a file-based approach) is probably the best way to solve it
#aaronpkotherwise i basically have to build my own locking mechanism, and processes the might write the file would have to request a write lock at the time they open the file
#tantekexactly. building your own locking mechanism = probability of building your own deadlocking mechanism ;)
#aaronpkso for now, since everything is queued and processed in a background task, i'm just going to reduce to one process so that everything happens sequentially
#sknebel_aaronpk: that's why I put different generated bits into different files for now
#sknebel_but that probably also gets annoying once you get to the point where changed fields start to overlap between tasks
#aaronpkthis wasn't a problem for me until i had two tasks that often take a long time. POSSEing being one, and fetching reply context (or repost content) being the other.
#tantekaaronpk: I'm surprised you're not fetching/caching the reply context as part of the authoring UI / flow
#aaronpktantek: that would involve every client being responsible for that task
#aaronpkinstead, i can have a client that sends only the "repost-of" or "in-reply-to" property as a URL
#tantekI suppose I would expect good UIs (clients) to *have to* do that purely for UX reasons
#aaronpki'm less certain about it for reply contexts, but it was convenient to do so
#tantekhmm, convenience seems like a bad reason to do that, and how data stores end up getting bloated with things they shouldn't have
#tantekrepost makes sense because you as the author want to absolutely capture the snapshot in time of the thing you reposted
#aaronpkwell i have to store it *somewhere* in order to render it. it was easier to put it in the post file than come up with a scheme for storing it outside the post file
#voxpelliI would store reply-contexts the way I store webmentions I think
#tantekright, my approach for storing that kind of thing is the same for webmentions - stuff from other sources, not me
#voxpelliin a threaded conversation the reply-context could even be the exact same data as the webmention I have already received on another post
#aaronpkvoxpelli: yeah that was what i was originally diagramming for this project, but i still haven't come up with a long term plan for storing webmention content
#aaronpkmy disk storage in p3k-v1 ended up having some issues that i haven't figured out how to resolve yet
#tantekbasically for each storage file I have (bim) I plan store a second file of the cached stuff from others
#tantekand yes that means two file loads instead of one, but it also means a very simple data / file persistence / cache policy
#voxpelliI store everything as json keyed on their normalized URL:s and then make them into likes, reply-contexts etc based on relations between that url and another url
#Loqino-www is a movement to deprecate use of "www." at the start of URLs as being redundant, unnecessary, and a waste of resources https://indieweb.org/no-www
#voxpellibut I only use the normalized URL for matching different URL:s against each others, to avoid duplicates and to allow for my embed code to actually find all mentions
#aaronpkpresumably two different URLs could overwrite each other in your storage tho?
#voxpelliyes, but only if someone has some very weird implementation
#voxpellidouble /, trailing / and www. most often have the very same content as any URL:s without it
#tantekKartikPrabhu: wat? they were not in the export?
#tantekI think I gave up on "meta" tags that sit outside the content storage
#KartikPrabhuthey were but they are stored as some "relational" thing and not as plaintext. So all tags got exported but the "relation" between them and posts broke :(
#tantekinline hashtags in the content are harder to "lose"
#KartikPrabhui did all this moving to make it easier to finally move to file-storage
#voxpellivery interesting though in relation to the earlier discussion of splitting up data among many files – can make data loss easier
#tantekany chance you can check archive.org for your tags on your permalinks?
#tantekvoxpelli: not quite sure I follow. the problem was the ethereal "relaional" things, rather than different plain text stores
#KartikPrabhuright, my original database setup was that "tag" is an object and "post" is an object and there is a "relation" betwen them that MySql magically manages
#KartikPrabhui am no DB expert so I made this after reading things on the web
#voxpellitantek: well, KartikPrabhu thought he had all pieces, but he didn't – the more spread out ones stuff is, the easier to forget one part. Having everything at the same place makes that impossible
#tantekvoxpelli: having everything in files in the file *system* is a form of everything in the same place, especially if they're in the same root folder
#voxpelliKartikPrabhu: usually no magic relations in MySQL, relations are something you most often define at query time there – matching one value against another. (Compare to eg. Neo4j where a relation is a first class object)
#voxpellitantek: well, formatting drives or erasing databases – both times you need to ensure that you have extracted everything you want or else rely on you having backups of things from before you erased it
#voxpelliKartikPrabhu: but since theres nothing magical, then maybe you have exported it afterall?
#KartikPrabhuyeah it is possible, I am looking at my export JSON to check that
#voxpelliif you can put parts of the export up somewhere we can have some more eyes
#KartikPrabhumy text editor is hainvg trouble with the large JSON file :P
#KevinMarksUsually you have an id on each, post_id and tag_id and table that has post_id, tag_id pairs in
#tantekright, ids for tags just in case you want to "rename" the tags and have them stay assigned to all the posts you assigned them to, instead of having the name of the tag *be* its ID
#KartikPrabhuyeah I think that database which has the post-tag pair didn't get exported
#KevinMarksWell, also to make the table fixed size
#KartikPrabhunow I am thinking of just storing the tags as a comma-separated text field
#KevinMarksThe question is if you need to make tag pages, are you better off with a db or a generation script
tantek joined the channel
#KartikPrabhuKevinMarks: yes, that is what I need to look into
#KevinMarksWith a static generator it will build the tag pages for each update