Developer forum

Hi Lara

We can - but it will always come with a performance overhead when using these queries so you should be very careful to use them.

The problem is, that the query it self can contain a lot of parameters that are affected by the current context - i.e. user being logged in, time, language, currency, shop, assortment etc etc. So we cannot just cache the result of the query - as that will in many cases would cause wrong results.

If you create a number of discounts that all uses queries, DW would have to search all queries for products on all product lists - and that will be relatively slow because it has to been done over and over again.

Anyways - I will re-open the issue to see if more can be addressed, but it will not be a quickfix. We need to rewrite some things...

BR Nicolai

Hi Nicolai,

I see your point about performance. Anyway we could have a compromise? In another thread we already talked partly about this. We need a solution for our customers to:

• Set up a query
• See what products that Query returns (just like in PIM)
• Associate that query to a Discount

In these scenarios, which for this customer in particular result in the majority of their discounts, caching that "list of products" is acceptable as the other discount conditions (i.e. user groups) take care of the other context scenarios.

In the meanwhile we'll work with them to use Queries (in PIM) to get the products and then apply them to "dummy" groups (unless you can think of an easier workaround for a backend user).

Best Regards,

Nuno Aguiar

So, you ask me to introduce a buggy feature for this customer only :-)?

How many discounts do they have like this? 1, 10, hundreds?

What does the queries do? Could it be handled with discount conditions as "If product field Y=X" then it is valid - would be much faster...

BR Nicolai

Hi Nicolai,

>> So, you ask me to introduce a buggy feature for this customer only :-)?

That's only if it's badly developed :P Kidding aside, it's not the first time a customer has asked to have a certain list of products associated to a discount. Up until now we tried to workaround that by having specific groups created, but for this on it's a harder compromise because of their marketing strategies and product data.

>> How many discounts do they have like this? 1, 10, hundreds?

They have created nearly 20 individual queries to get products that match a certain criteria to assign to discounts. Currently they even have to user multiple queries in the same discount. I can't say how many will work at the same time, nor if this list will grow or just be updated over time, but I wouldn't be surprised (for this customer) to have 20 active discounts.
You can access https://qa-sweetums.dw-demo.com if you are curious as to what they did already.

>> What does the queries do? Could it be handled with discount conditions as "If product field Y=X" then it is valid - would be much faster...

Yes. They just need a dynamic way to "group" products together based on their own data, no user or pageview context involved. The most complex data to query would be "release date", where they would want to query products release last year (just an example for now), so I need a query products where the (custom field) Release Date is between 01-01-2018 and 31-12-2018 (we had a different thread going with this).

I totally agree that queryes with User, pageview and other context data cannot be as performant.

A number of possible solutions - can be combined

1. Add an option to do If productfield X=Y, discount apply. That would work for several of the discounts on this solution.
2. When selecting a query, find the products and add them as a 'static' list on the discount - like if they have been manually selected
3. Add a 'caching in minutes' input box on the discount related to the query. Which I know I will receive a trissillion bug reports on...
4. A complex caching matrix of checkboxes defining what context to vary by. (Out of the question)

What you say?

NP

Hi Nicolai,

1. I believe this option would work for some customers, but I can easilly see people asking for more and more conditions.
2. This seems like a great solution, because it means we have the flexibility of queries
3. Hate it :)
4. Hate it even more :)

Best Regards,

Nuno Aguiar

Hi Nicolai,

As of no surprise to me, the first question the customer asked was the time-frame to get this done. Do you have any thoughts about that? And if so, would it be something I could update a package so we wouldn't have to upgrade to 9.6?

Best Regards,

Nuno Aguiar

Hi Nicolai,

Can you provide me with any estimate as to when we could expect this?

Best Regards,

Nuno Aguiar

There are no plans for this yet.

Ok, thanks

HI Nicolai,

Just checking in to see if you have an update and/or a TFS item so I can track it myself.

Best Regards,

Nuno Aguiar

No we do not.

But see this thread: https://doc.dynamicweb.com/forum/ecommerce-standard-features/ecommerce-standard-features/discounts-for-anonymous-users

Then you can make your own 255 parameters and code away :-).

BR Nicolai

Hi Nicolai,

I want to "re-open" this thread. Your option 2 from of of your posts back in Feb 25, seems an acceptable solution for this that would prevent custom development.
"When selecting a query, find the products and add them as a 'static' list on the discount - like if they have been manually selected"

Could this please be added to Dynamicweb? I am imagining a simple list that can be cached the first time the discount is rendered and have the list be cleared if the index is rebuilt. I understand I may be oversimplifying it, but seems something doable and better implemented in the Core product.

Best Regards,

Nuno Aguiar

Hi Nicolai,

Can you please revisit this and let us know if option 2 you presented back in Feb 25 can be added to DW?

Best Regards,

Nuno Aguiar

It still cannot. It is not the right solution - it will be buggy, and I will not do it. All the macros will not work, as they expect a frontend context...

You can create queries in PIM, and use them to publish to ecommerce to add the products to specific groups.

Sorry!

Hi Nicolai,

Ok, very useful to know. That means we'll clearly find an alternative.