- So... The database was properly imported, the scraper is now retired. It took me weeks to refine you, and in the end you only officially served for a bit over a month, still, thanks for existing!
- I'm now linking matches to user profiles on Lestrade's, rather than Barter.
- 'Inactive' links are now related to the user's last time on LT. The current threshold is one week. If you went online in the last week, you're "active". There is currently no option to mark your account as on hiatus.
- Ability to add/remove to your list is still being worked on. Give me another half hour. I wasted time writing this very post and thinking about consequences etc. This is the last thing stopping me from opening the offer system, so I'll need feedback! Here's my concern:
I was looking at my offer system, and more particularly the code that triggers when marking as completed. It removes the tradable from your list, but... Then it's no longer in the database, okay? And the offer system stores items by tradable ID, so that we can forever know that an old trade was for instance made for a Steam gift rather than cheap key of 'Bad Rats', or that it was tagged in a specific way, like "this copy is region-locked to France". However, if I remove the tradable from the list, it's data I can no longer access.
I'm looking for opinions on what to do. Since many of you are developers, and you wanna help, I'm open to suggestions really.
1/ Store tradable AND game ID in the database. It doesn't take too much space. That way, when the tradable is removed, at least we still know what game was in the trade. Who cares about whether it was a Steam gift...
2/ Store tradable, game ID, and trading tags from tradable. This potentially takes a lot of space. The advantage is I can limit the trading tags to what's important to trading, and clear them if the offer is not accepted, or it's accepted but that item isn't in the list of selected items.
3/ Store tradable only, and ALWAYS keep the tradable in the tradable table, except mark it as no longer owned. (Like, set quantity to a potential 'NULL' value, rather than zero.) This takes the most space out of all solutions. The tradable table is already quite large as it is. I can hardly imagine how large it would be if I kept all tradables from older trades. But this is probably (?) what Barter did, because I think it kept track of the store for each bundle item in an offer, even after canceling it and removing the item from your tradables. (Or did it???)
4/ Store game ID only, not tradable. Store tradable in a TEXT field along with ALL information on available items. Reduce TEXT size to minimum information needed after offer is completed. Because TEXT fields are stored in a file external to the database files (the database only holds a pointer to the object and its size), it's less likely to cause performance problems in the long term. I could even store those details in simple text files somewhere on the server, why not.
I'm more likely to go for option 1, the 'realistic' one and easiest to implement (given how much work I have, it wouldn't be a bad idea...), or option 4, the complicated but possibly most useful one.