I want to model a bundle in commercetools which contains two different products and both these products have different quantities in it.
For ex:
Bundle A
Product X | QTY: 1
Product Y | QTY: 3
Bundle B
Product A | QTY: 2
Product B | QTY: 5
I have tried modelling this using custom objects but it seems it is not a good fit. I am looking for other possible solutions to achieve this. Also, I would be interested in solutions that support expansions so that I can retrieve the details of the products in the bundle without an additional request.
Thanks in advance.
you could try to model this similar to what is described in our product bundle tutorial in the commercetools documentation.
https://docs.commercetools.com/tutorials/product-bundle-api#top
Related
So I'm creating a vue.js app and using Firebase as a back-end service. I have gotten some knowledge now on how one can store data in firestore but I'm asking what way would be the best for my case. At a certain point in the app, users can complete orders where each order has certain products. Every order will have an average of let's say 5/6 products, which are objects. Which of the following ways to strcture this data would you suggest?
orderedProducts as a top-level collection: here every document in this collection would have a reference to the order. Since I only need the products related to one order, I think this would be a bad choice. The relation is somewhat gone?
subcollection: here products can be a subcollection of orders. Nice hierarchy / structure but increases document reads compared to embedded array.
array: products is embedded as an array inside an order document. This is what I have now and is the easiest approach to create.
I thought, since the amount of products per order will be rather slim, I just use an array of products inside my order document. But ofcourse I might be wrong, or missing some important stuff.
I would appreciate any help/pointers on this real-life example on how to structure these products per order.
Thanks!
A possible schema for your app's use-case might be:
Firestore-root
|
--- merchants (collection)
| |
| --- merchantId (document)
| |
| --- //merchant details
|
--- orders (collection)
|
--- orderId (document)
|
--- merchantId: "LongMerchantId"
|
--- products (array)
|
--- 0
| |
| --- productName: "Bacon"
| |
| --- productPrice: 5
|
--- 1
|
--- productName: "Eggs"
|
--- productPrice: 12
Using this structure you can easily query for all orders of a single merchant:
db.collection("orders").whereEqualTo("merchantId", "LongMerchantId");
To get all the products of a particular order, simply use the following reference:
DocumentReference orderIdRef = db.collection("orders").document("orderId");
Now you can attach a listener on this reference, get the document and use the products list. You didn't specify the programming language that you are using so I gave you the examples in Android. It's very simple to transform them in the language you are using. For Android, to get a list of custom objects, please check the following article:
How to map an array of objects from Cloud Firestore to a List of objects?
One more thing to note is that the solution above will work only if you are sure that products in an order will fit in a 1 MiB (1,048,576 bytes). If you are not sure, instead of an array you should use a sub-collection. If you want to be 100% safe, you can always check against the maximum quota, using FirestoreDocument-Android library.
I'm designing a database for an online-store.
The store has different kinds of products (different categories: cosmetics, multivitamins, etc)
Each product has different options (color - package size - etc)
this options can effect on the price (like package size) and also each product with specific options varies in stock for example :
golden rose lipstick- color: red - price:50$ -stock: 50
golden rose lipstick- color: red - price:50$ -stock: 70
some kind of multivitamin - package size:60 tabs- price: 60$ -stock:5
same kind of multivitamin -package size :120 tabs- price:100$-stock:6
how should I design product table to store all options with stocks and price ?
I need a way which would be efficient for filtering products based on their options.
Well just store it like the actual physical products. So treat each size and color like an individual product, because that's what it is. You can also check out how Magento did it in their database. It's good to look at how the competitors do it :)
http://excellencemagentoblog.com/blog/2011/09/07/magento-eav-database-structure/
I want to build the data basis for what could be a decision tree. The data I have is the following:
|Customer ID| Previous product| New product | Date |
I want to represent this so that I can drill down to analyze which product paths our customer take, for example product A -> product B -> product C, or maybe is it most common to go from product B -> product C -> product A.
I was thinking on making a column for each of the 5 latest products, however I am unsure if this is the best way of doing this. How can I represent this
My search results for Electric blanket brings up all products specific to electric/blanket/electric blanket". However, I need results only specific to electric blanket.
The query my application sends to SOLR has :
q="electric" "blanket"
What change is required at SOLR config end to make this search only for electric blanket?
In your schema.xml, add to the end of the file, before </schema>:
<solrQueryParser defaultOperator="AND"/>
Solr Documentation: https://wiki.apache.org/solr/SchemaXml#Default_query_parser_operator
in SearchSetup.jspf make the default value of searchType = 1001 instead of 1000
<c:set var="searchType" value="1001" scope="request"/>
below is the explanation - also you can find complete list in same file :
13. ANY | 1000 | INCLUDE products, kits, bundles, category level SKUs
| (Default) | EXCLUDE product level SKUs
| |
14. EXACT | 1001 | INCLUDE products, kits, bundles, category level SKUs
| | EXCLUDE product level SKUs
| |
15. ALL | 1002 | INCLUDE products, kits, bundles, category level SKUs
| | EXCLUDE product level SKUs
EXACT will force solr to match the whole sentence , same as when you type your search term in inte qoute "search term" , that will search in products that have EXACT sentence in product name , short description , category name , SEO Keywords , name override and description override
Hope this answer you question.
Thanks
Abed
You can not have results only specific to just electric blanket. You can however ensure the results specific to electric blanket are more relevant and returned at the top of your results.
The configuration of Solr that Websphere Commerce offers out-of-the-box is very basic. In order to receive desired results takes a lot of tuning and configuration changes in both Solr and Webshere Commerce (We resorted to writing a custom class). sarona.co.uk has some nice information about this in their latest blogs.
This is a system architecture question on designing full-text search with (relational) database. The specific software I'm using are Solr and PostgreSQL, just FYI.
Suppose we are building a forum with two users Andy and Betty --
Post ID | User | Title | Content
--------|-------|-------------------|---------------------------
1 | Andy | Dark Knight rocks | Dark Knight rocks blah
2 | Betty | I love Twilight | Twilight blah blah
3 | Andy | Twilight sucks | Twilight sucks blah
4 | Betty | Andy sucks | Twilight rocks, Andy sucks
When the posts table is indexed in Solr, we can easily return the posts sorted by their relevancy to "?q=twilight" or "?q=dark+night".
Now we want to add a new feature to search for users instead of posts. A naive implementation would simply index user name and return "Andy" to "?q=a" and "Betty" to "?q=b", but what if we want to make our system smarter to also take into account of the user posts and return "Betty" before "Andy" to "?q=twilight" because Betty mentions Twilight more than Andy does.
How would you design the system to efficiently handle the user-search function for hundreds of thousands of users and millions of posts?
Faceting on User would return number of results per user. If Andy wrote 15 posts that match Twilight while Betty wrote 10, the faceting will return them as such.
But it wont help if both wrote 15 posts about Twilight, but Andy's was supposed to be more relevant; you will see all facet counts (15, 15 in this case) even if you are paginating to see only (say,) top 5 results and Andy made 4 of them.
If above solution is not good enough, consider a background job that writes documents of
type: suggest_user_type (so you can distinguish them by a `fq`)
user: Andy (the user)
concatted_posts: "I think Twilight.." (concatenate the users latest 50 posts)
once a week. And if you
fq=type:suggest_user_type&
q=concatted_posts:twilight&
fl=user
you get a sorted list of users based on relevance of concatted_posts with respect to twilight.
I believe term frequency is included in full text search ranking. It's part of a research area called information retrieval. There's also another value called the inverse document frequency, which filters out common terms.
There are other steps common to ranking text, you may want to have a look at the OpenNLP project if you're interested.
In terms of database design, there's too much to cover in a post and I'm not the one to write it. The general consensus seems to be for very large systems they key is building an efficient index, then distributing this over a number machines to scale performance. I would recommend reading up on Page Rank and how Google developed its systems as a starting point.