Hi I have a little question about these product combinations in prestashop. We are implementing a integration for our Warehouse Management System that imports products from prestashop via Webservice.
Now to the problem. Lets say there are a t-shirt with different sizes Small, Medium, Large.
If i import with /api/products?display=full I got only one id for the sizes. How should i Map for example a tshirt Small with a unique id.
Some example i thaught of was if it was possible to combine the product id for example 1 with combination 14 than it will be 114. But its not a safe way because it may be a product id 11 with combination 4.
And in order import i got product attribute id. How to map it to correct combination?
Related
I have 5 different models....similar structure but seperated due to lots of record so easier management and scalability.
I'm not sure if this is possible with django, but i have a div on the website which is called latest....i want to grab the latest 3 records and show it in this div....however having 5 different models its difficult....each have a timestamp field. Is it possible to query something like show latest 3 records in total, but check 5 of these models and display?
Usually if it was in one model I could have just easily said show latest x....but separated models makes its complicated. So i don't want to grab latest 3 records from each model....rather 3 in total but just consider from 5 different models and show latest 3 (either through filtering of id of timestamp field)
Please kindly let me know if there is a solution.
There is two different solution.
At first you can merge models and make a general model with common columns and each of 5 models connect to general model with ForeignKey. So you can make query on general model and access specific columns with related objects.
Second way is usingdjango contenttypes framework
Background:
My customer's shop has Internet wifi for customer and also his staff.
Shop owner would like to visualize the heatmap of his shop in order to arrange the desk and furniture for sake of convinient.
Schema:
https://gist.github.com/elcolie/7bb56c286afacadff63eccae94bda713
Goal:
1. I want to determine mac address to be a pin_value
Constraints:
1. One mac can has many imc(username). Public computer serves many customer
2. One imc can has many pin_value. Customer got promote his pin
3. imc does not need to has pin_value. Staff account has no pin_value
4. mac does not need to has imc. May be somebody their just passing by without turn off his wifi
Question:
How do you use conditional expression to do single query and get mac:pin_value?
My poor solution is brute-force search which is very slow.
Location model has record per day is about 100k rows.
I have 4 tables in my database. The image below shows the rows and columns with the name of the table enclosed in a red box. 4 tables total. Am I going about the relationship design correctly? This is a test project and I am strongly assuming that I will use a JOIN to get the entire set of data on one table. I want to start this very correctly.
A beginner question but is it normal that the publisher table, for example, has 4 rows with Nintendo?
I am using Django 1.7 along with PostgreSQL 9.3. I aim to keep simple with room to grow.
Basically you've got the relations back-to-front here...
You have game_id (i.e. a ForeignKey relation) on each of publisher, developer and platform models... but that means each of those entities can only be related to a single game. I'm pretty sure that's not what you want.
You need it the other way around... instead put three foreign keys onto the game model, one each for publisher, developer and platform.
A ForeignKey is what's called a many-to-one relation. In this example I think what you want is for 'many' games to be related to 'one' publisher. Same for developer and platform.
is it normal that the publisher table, for example, has 4 rows with Nintendo?
No, that's is an example of why you have it backwards. You should only have a single row for each publisher.
yes you are correct in saying that something is wrong.
First of all those screen shots are hard to follow, for this simple example they could work but that is not the right tool, pick up pen and paper and sketch some relational diagrams and think about what are the entities involved in the schema and what are their relations, for example you know you have publishers, and they can publish games, so in this restricted example you have 2 entities, game and publisher, and a relation publish among them (in this case you can place a fk on game if you have a single publisher for a game, or create an intermediary relation for a many to many case). The same point can be made for platform and games, why are you placing an fk to game there, what will happen if the game with id 2 will be published for nintendo 64 ? You are making the exact same mistake in all the entities.
Pick up any book about database design basics, maybe it will help in reasoning about your context and future problems.
I like to develop a shopping cart website with multiple products.
(ex.: mobile phone, furniture etc.,)
here mobile phone specification will cover
size of display
memory
operating system
camera etc.,
but for furniture - its specification is entirely different from above electronic product.
type of wood
color
weight
shape
glass or mat finish etc.,
My question is: how to handle a common database-table for product specification ?
each & every category of product & its spec will be differ - so how to have a common
table ProductSpecificationTable ?
I searched many site including google.. but cant able to get the perfect soultion.
Please help me to move to next step.
Ask yourself the question: How can I accomplish this kind of database? First of all you need products.. Every product has to be in some kind of category and every category has to have his own properties. So, you've to create a product table with unique id and every product needs a category id. At this moment it is time to link from your property table to your category table(by id) and to set the values you need a 'property_value' table.
**table:** **id**
product --> category id
property --> category_id
property_value --> property_id
I hope you will understand my explanation otherwise just ask :)
You can add 1 more table to accomplish that. Table that contains cat_id, product_id and the property. That is a many to many relationship. I believe this way you can accomplish thst.
You can achieve this with a single table within a database but that will complicate the CRUD operations over the table. So I will recommend you to create one database like ‘Inventory’ which can have multiple tables (one table for each of the Product Type).
First Table could be list of Product Types you have (mobile phones, accessories, furniture):
You can use this table to populate your list of items available. Here the column _table_name will contain the actual name of the Tables.
Then for each of the product you can have different tables with different number of columns:
Table for Product Type Mobile Phones:
Table for Product Type Furniture:
I hope this will help.
In django I have three models:
SimpleProduct
ConfigurableProduct Instead of showing several variations of SimpleProducts, the user will see one product with options like color.
GroupProduct - Several SimpleProducts that are sold together.
First I'm creating all the SimpleProducts, then I create ConfigurableProducts from several products that are variations on the same product and last GroupProducts which are combiniations of several SimpleProducts.
When a user navigate to a category I need to show him all the three types. If a SimpleProduct is part of a ConfigurableProduct I don't want to show it twice.
How do I make the query? Do I have to create three several queries?
How do I use pagination on three models at the same time?
Can I somehow use inheritance?
Thanks
I think this question is tough to answer without understanding your business logic a little more clearly. Here are my assumptions:
Configurable options are ad hoc, i.e., you sell balls in red, blue, and yellow, shirts in small, medium, and large, etc. There is no way to represent these options abstractly because they don't transcend categories. (If they did, your database design is all wrong. If everything had custom color options, you would just make that a column in your database table.)
Each configuration option has a pre-existing business identity at your company. There's some sku associated with red balls or something like that. For whatever reason, it is necessary to have a database row for each possible configuration option. (If it isn't, then again, you're doing it all wrong.)
If this is the case, my simplest recommendation would be to have some base class that all products inherit from with a field: representative_product_id. The idea is that for every product, there is a representative version that gets shown on the category page, or anywhere else in your catalog. In your database, this will look like:
Name id representative_id
red_ball 1 1
blue_ball 2 1
green_ball 3 1
small_shirt 4 4
medium_shirt 5 4
large_shirt 6 4
unique_thing 7 7
As for django queries, I would use F objects if you have version 1.1 or later. Just:
SimpleProduct.objects.filter(representative_id=F('id'))
That will return a queryset whose representative ids match their own ids.
At this point, someone will clamor for data integrity. The main condition is that representative_id must in all cases point to an object whose representative_id matches its id. There are ways to enforce this directly, such as with a pre_save validator or something like that. You could also do effectively the same thing by factoring out a ProductType table that contains a representative_id column. I.e.:
Products
Name id product_type
_________________________________
red_ball 1 ball
blue_ball 2 ball
green_ball 3 ball
small_shirt 4 shirt
medium_shirt 5 shirt
large_shirt 6 shirt
unique_thing 7 thing
Types
Name representative_id
_______________________________
ball 1
shit 4
thing 7
This doesn't replace the need to enforce integrity with some validator, but it makes it a little more abstract.
Go with Django's multi-table inheritance, with a base class you won't instanciate directly. The base class still has a manager you can run queries against, and that will contain the base attributes of any subclass instance.
To tackle your question about configurable products that must not be displayed redundantly, I think you have two options:
Make configurable products a multiple choice of ConfigurableProductChoice (unrelated to SimpleProduct). Have the ConfigurableProductChoice extend the ConfigurableProduct. That way you'll have a single ConfigurableProduct in your results and no redundancy.
Make configurable products be associated to various options, and design a rule to compute the price from what options are selected. A simple addition would be fine. Your product IDs will need to encode what options are selected. You still have no redundancy, because you didn't involve SimpleProduct.