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
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
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
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.
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
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
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
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 :(
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
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
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