Multistore fields

[datakick]

Hi,

I just wanted to start a discussion about multistore fields (fields that can have different values in different shops, when multistore is enabled)

What bugs me is that values are stored in two places in database. Let's have a look at product base price - it's stored in tb_product.price and tb_product_shop.price. Whenever you save product, the value is stored into both two columns.

Everything is OK as long as you don't enable multistore feature. (well, not really, as values in these two tables can quite easily become out of sync)

Once you enable multistore the values of multistore fields in tb_product table will behave strangely. This table will always hold the value of the last updated shop.

Example: I have shop A with USD as default currency, and shop B with EUR currency.

I create shared product, and edit it in shop A context. I set base price = 100 USD. When I hit save, then the number 100 will be saved in both tb_product.price and tb_product_shop.price columns. So far so good.

Then, I edit the product in shop B context, and set price to 80 EUR. After save, ```tb_product.price`` will contains value 80.

As you can see, the tb_product.price can very quickly became mix of total nonsense. Every piece of code that uses this column will NOT work correctly when multistore feature is enabled. As an example have a look at product list in back office.

Solution

The solution is obvious but not trivial - get rid of these columns and fix all references in code. Let's have single source of truth.

It is definitely not backward compatible. But I believe it would make the whole product much more stable.

Just something to thing for version 1.1

[Traumflug]

Let’s have single source of truth.

Yes, good point. This means to get rid of the distinction between monoshop and multishop. All shops are multishops. Monoshops are multishops with just one shop defined.

The question arising is, what's the gain for merchants? It's hard to justify a larger overhaul of pretty much the whole software, just to make the database layout a bit more pretty. Such a change also likely breaks lots of modules, so have your flameproof suit handy :-)

[datakick]

@Traumflug said in Multistore fields:

The question arising is, what's the gain for merchants?

The benefit for merchants is, well, bug-free system :)

As I wrote in my previous post, every code that actually access data from tb_product.price instead of tb_product_shop.price is bound NOT to work correctly in ALL scenarios. There will be some settings where this code fails terribly, and it will produce strange errors / confusions. What's worse is that there are many scenarios when this code works just fine. And that makes the whole debugging / fixing much more harder.

To demonstrate these weird errors, let's continue with my example from previous post. Let's say there is some module that will apply a discount only if shopping cart contains a product whose base price is more than 90 USD. And let's say this module works solely on tb_product.price . Then the discount would be apply only if the product was last edited in shop A context (because tb_product.price == 100). If, however, any employee edits the product and change any value in shop B context, then tb_product.price == 80, and the discount will not be applied. These kind of transient bugs are crazy, don't you think?

I totally agree this is very hard change, and I'm not suggesting that it should be done. But it's a huge technical debt. That's why I raised this thread - to brainstorm what can be done.