Sylius: [Shop] Popular products

[psihius]

Hello!

I'm trying to implement the most popular / most bought products list. As far as I see, the DB structure was not really meant to do this, and I have trouble coming up with a proper query builder expression for this.

Is this possible at all? I see that we can I can go: product => product_variant => order_item, but I have trouble building the query builder query, as there are is no relation between product and it's variants due to different methods. Also, I just need to do a COUNT with GROUP BY by product id and order descending by that counted field. Any suggestions how to build this monster?

[okwinza]

The suggestion is to don't build it at all. For your case all you need to
implement is some kind of logging logic for every purchase being made.

Out of my head: Create new entity ProductVariantStatistic with fields like
"timesSold", etc, bind it 1-1 to productVariant, create a handler which
scans the order and increment fields of the entity, bind this handler to
order state machine, profit.

On Mon, 19 Dec 2016 at 10:23 Arvids Godjuks [e-mail]
wrote:

Hello!

I'm trying to implement the most popular / most bought products list. As
far as I see, the DB structure was not really meant to do this, and I have
trouble coming up with a proper query builder expression for this.

Is this possible at all? I see that we can I can go: product =>
product_variant => order_item, but I have trouble building the query
builder query, as there are is no relation between product and it's
variants due to different methods. Also, I just need to do a COUNT with
GROUP BY by product id and order descending by that counted field. Any
suggestions how to build this monster?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Sylius/Sylius/issues/7121, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpfTGzG-XvdfYAdfDFLaBhgORV-tFyks5rJjD6gaJpZM4LQcFm
.

[psihius]

@okwinza probably better to assign it to product, because product variants, as far as I can see, are not shown as their own products. All variants probably can contribute to the product counter :)
This probably will warrant a Pull Request

[okwinza]

@psihius the core of product relations is productVariant. Product is just a group of variants. Having info about sold variants you can easily build a query and group them by products or do whatever you want.

Also note, that order contains variants, not products.

[okwinza]

Since @pjedrzejewski marked this as RFC, i'd like ot share some more thoughs on this.
First, it'd be cool to have such feature in core but if we go this way, simple counter is not enough. We also need a link to the actual order.

So the actual question is: How to implement this in sane and extendable way without any performance loss?

Here is my take on this.

interface ProductVariantStatistic {

  public function getPurchases();
  public function addPurcase(Purcase $purcase);
  public function removePurcase(Purcase $purcase);

  public function getVariant();
 //no setVariant() here, $variant property is immutable after construct

}

interface Purchase {
  //immuable aswell
  public function getOrder();
  public function getVariant();

}

Additional notes:
1) Mark ProductVariant <-> ProductVariantStatistic relation as EXTRA_LAZY.
2) ???

WDYT?

[gabiudrescu]

maybe this can help as an inspiration? https://github.com/webburza/sylius-customers-also-bought-bundle

if you think, product association could be the link entity you are talking about - right? of course, yours describe a narrower scope.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.