sebi wrote:The user settable flag has the problem of affecting a very large amount of code and pages, because it's basically a special case in pricing. [...] I do ideally like this [flag-based] solution in principle as a user. But as the developer this will cause weeks of work and guaranteed future hidden bugs. The solution of separate printings (either with another edition, or with other collector numbers) gets rid of all these complications, since it's gonna be just another printing, that is foil (but with an "e" on the number, or as a note).
@Sebi — I've refrained from commenting until now, as I've already said a great deal on this topic. But I think I've figured out the solution.
The issue comes down to a conflict of short-term vs long-term needs: In the short-term, the community needs something ASAP so that they can start entering their etched cards into their inventories. In the long-term, Deckbox needs a sustainable, elegant solution, and almost all of us, including you, have agreed that a flag-based solution is just that (with only a few users voicing opposition, like psrex above, although his concerns with an etched flag can and should be dealt with in other ways). Unfortunately, the two needs do not jive, because meeting the long-term need will not allow for meeting the short-term need (due to development time).
The solution to this conflict? A planned migration:
STEP 1: Implement a temp system to meet the short-term need — Import the cards to the database however seems best in the short term (additional editions, different card names, custom collector numbers). Just ensure that there'll be a one-to-one relationship between an etched card in this temp system and an etched card in the final system.
STEP 2: Develop the long-term solution — Spend the time you need in updating your code in the background. I understand that it'll entail weeks of work, but it does seem like this will be a worthwhile time investment in the long run. In fact, take the opportunity to completely overhaul the pricing code, so that it's as modular and extensible as possible, to account for potential future weirdness from WotC (which is pretty much guaranteed, am I right???).
STEP 3: Release and migrate — In conjunction with releasing the updated pricing and flag engines, announce some planned downtime. During that downtime, run a script on the database that migrates everybody's inventories to the new system. It would see, e.g., Profane Tutor #401 from Modern Horizons 2 ETCHED and convert it to Profane Tutor #401 from Modern Horizons 2 with the etched flag set. Upon completion, delete the erroneous editions.
STEP 3a: Handle CSV imports — The only wrinkle in the above would be people like me who regularly export their inventory to CSV, then who might try to re-import after the migration, causing a long list of errors. You have two options: Leave it to the end-user to fix the "non-existing edition" errors, or create custom code to fix it for them. The only reason the latter might not be preferable is if it would cause a major performance bottleneck to the CSV import. But if you do a quick check for the existence of the erroneous editions within the CSV first, and only run the custom code if it returns true, the performance slowdown would only affect these few edge case users.
In summary — Don't compromise on the correct long-term solution out of short-term convenience or expedience. Instead, give us users a temporary way to handle our etched inventories, then gracefully migrate us over to the long-term solution once it's fully ready.
3 (100%)
