Add shops and shop_inventory_items

[mlapeter]

Hey Mark,

We've added shops and shop_inventory_items. Next we're planning to clean up the views so a player can view shops and items in shops. We left out quantity because you didn't mention it, if that's something you want us to tackle at this stage let us know. We're also planning to add a materials table in the future to deal with normalizing materials, does that make sense?

Thanks!

[mlapeter]

We've added wrapper methods to shop for the shop_inventory_items join table, should be ready for review and merge. Thanks!

[mlapeter]

We've also now added buy and sell actions to the shop model and on the view.

[mlapeter]

We finished the buy and sell methods for shops. Had a philosophical question about whether to use exceptions or soft errors for the buy and sell methods. We had one case where it was returning false at the end of the method but still silently updating records.

[duncantmiller]

Hi Mark - this branch is ready to be reviewed for merge when you have a chance. Thanks!

[marktabler]

I see what we're doing here, but the name is close to some existing Rails Magic and might cause confusion. How about def ensure_stocked(good) ? Or something like that.

[duncantmiller]

Hi Mark,

We've added the second polymorphic join table called wares and a module called vending. There were a number of methods in the vending module (quantity_of(good), has_enough(good) etc) that we duplicated from the owning module. We were wondering what you thought about the best way to solve this. Thanks!

[marktabler]

Good question! On the surface, the code looks wet - we're talking about the same quantity / existence concepts in two different places. But, they're working explicitly with two different pools of data - even if the logic is the same, we either need to call separate methods or genericize some of them to make this work. I don't anticipate going to more than two sets of goods a thing will need to manage, so leaving them as separate modules is OK -- though I might change the name of some of the Vending methods - e.g., @shop.ware_has_any?(good) doesn't read as smoothly as @shop.has_any_wares?(good).

But, there is a way we could reasonably refactor - and if we started getting in to more than two sets of goods per owner, we would almost need to. Here's an example of the way this refactor would work:

def has_enough?(source, good, quantity)
  subject = collection(source).find_by_good_id(good.id)
  subject && subject.quantity >= quantity
end

def collection(source)
  self.send(source)
end

Now, has_enough? takes three arguments: the familiar good and quantity, as well as a source. Source is going to be a symbol representing one of the collections we might have; currently, either :wares or :possessions. So, what's happening is that when we say @shop.has_enough?(:wares, Good.first, 50), the collection(source) method will run :wares as if it were a method - that is, just like @shop.wares. Just make sure you're never letting "source" be user input - this should come from things that are hard-coded in our app, not from passing params.

As you're doubtless noticed, this pretty much boils down to the same idea either way - we're going to have to specify whether we're talking about wares or possessions when we run methods like has_enough?. We'll also need to keep track of which collections respond to which methods (e.g., we have to know we can't call sell_price on a possession). So, I think that if we wanted to leave the two modules as they are for now, I wouldn't argue. If we wanted to refactor this into a generalized solution, I wouldn't argue with that either. If we go down the refactoring path, we'd put all the methods into one module (I'd suggest that Owning is still a valid name for a module that handles all kinds of belongings), and still manage transactions through intermediary class(es), such as Quartermaster.

It's your call as to what you think feels better. I don't think we currently have any requirements that would guide us especially one way or the other. I do think it's worth pointing out that if we were to get a requirement that made the decision for us, it would almost certainly be in the direction of dynamic source selection, but there's also no indication we will be getting any such requirement.

[marktabler]

Also, I had to take the nil fixes out of the migration file after all. For some reason, our model names were not recognized during runtime - this might have something to do with database state & environment settings. In any event, it's in a separate rake task in case we need it for maintenance later but we can probably delete it entirely pretty soon (if nobody has broken data, and the migrations prevent it from breaking, then the repair task is obsolete.)

Still not sure why it doesn't work in the migration - the Rails docs themselves suggest it ought to - but at least now we have reasons for an opinion about where that code should live. :)

[duncantmiller]

I think I know why... Mike and I created another migration today to delete those tables and also deleted the models, since those were for the old shop_inventory_items and character_inventory_items.

[mlapeter]

Ok, we believe we're done with transactionable and Quartermaster, and we've added tests for all the cases we can think of. Please review and merge if it's ready and let us know what you think!