I'm trying to enable the price rules on my product. I need a discount on all my catalogue.
So I create a rule not touching condition to include all product. I set all following a guide, so I don't think to have made something wrong but the rule don't apply to the catalog.
Tables catalogrule are all empty
Do you have any idea?
You have configured the rule and activated it. Verifying shows that this rule does not change price for desired group of products.
One more reason of rule inefficiency is that you have not applied it. If you have just created Magento catalog price rules or implemented some modifications, apply them pressing correspondingly Apply Rules button on the toolbar.
Review attached image for more clarification.
I've found the solution. I write for othern that need it.
I had loaded demo contents in my store and there was also price rules. The catalogrule table had ID = 11 for my rule.
I need to reset the autoincrement to 1 and it start to work!
So remove all rules and execute this query to the SQL DB
ALTER TABLE `catalogrule`AUTO_INCREMENT=1;
Then create again the rule and apply it! It will work!
Related
I found this in an old post and i'm thinking of using it for a project, but i don't know if i should change it or leave it, here's what i want to change:
remove product options and add product id and option group id to options
remove order details and have it's info in orders
is what i'm doing bad? also if you could be kind to tell me some of the best practices for something like this i would greatly appreciate it.
thanks for your time.
Both tables are there for a good reason.
productoptions is a mapping table between options and products: this is a many-to-many relationship, where a given product may have multiple options, and an option may be used by multiple products. If you remove this table, you end up redondantly adding the optionName to each and every row in productoptions that relate to the same option, which is inefficient, and might break data integrity (how do you ensure that a given option always has the same name?).
As for order_details: this is a many to one relationship towards orders. An order may have mutliple details line, each referring to a different product. Removing this table means losing this possibility.
I'm updating an old MySQL database and find that several columns in various tables are not needed. But rather than just remove the columns, I'd like to disable them temporarily so I can test the code and see how many things break before I decide to complete remove the column. How can I tell the server to throw an error if a particular column is accessed?
You may rename table oldname to newname and create view using oldname. that view look like column removed table. if have some problem. you just change name table and view.
You might want to consider using a view for this. As an example I created this fiddle : http://sqlfiddle.com/#!2/a8947/2
Take a look at the two queries. One selects the table with the column you aren't sure you need (which I called "legacyData"). The other selects the view. You can see that in the view, the column "legacyData" no longer exists.
I don't think this will work if you are writing from the table, but if you are reading from the table a view is a viable option.
The steps you'd want to take in production to try it out would be:
Rename your table ('myTable' to 'myTableDontUse', for example)
Create the view based on the newly renamed table
When you name the view, name it the table's original name (myTable in this example)
By doing that, you've replaced your table with a view. This approach would allow you to see if applications are accessing the legacyData field of that table. If not, you can remove the view, rename your table, and drop the column in question.
Performance typically is not great with a view especially if you have a lot of data, so be careful of that. In a similar situation, I started out with a view but due to performance reasons (table had 2M+ rows), we changed to a normal table that was instead populated via triggers.
I think my question was a little confusing.....It confused me :)
Working on a media site as a take-over project and it has a custom CMS. The client wants the ability to activate/deactivate media....sort of like Wordpress's publish/unpublish feature.
Instead of digging through all the code looking for mysql queries (which I'm not opposed to), I was wondering if you can add a sort of INDEX to a table that won't let it return result rows if that rows "active" column = let's say 0.
Just trying to be lazy and learn something at the same time, heh.
I don't need examples of queries to make it happen, btw.
What you describe is called a "view". Here is a page describing how to create them in MySQL: http://dev.mysql.com/doc/refman/5.0/en/create-view.html. However, in most cases you will still have to alter your code to use the view instead of the table.
You can consider create a view (which contains active record only)
AND swap the view name to actual table name instead, so you can achieve the negative filtering without changing any of your source code.
I have a MySQL table , each row representing a Person. For each person I would like to show a list of related links (when generating his page on my website), so I created a column called "RelatedLinks" which there I save raw HTML content such as:
Related Link 1 Related Link2
Then I just use PHP to echo $row["RelatedLinks"]; within the HTML itself.
The problem with this implementation is that I have little control over the links, for example in changing their order of appearance on the website, deleting/editing a specific link and so on.
The second idea I thought about was to create a column in the table for each related link, such as "RelatedLink1", "RelatedLink2" and then use PHP to echo $row["RelatedLink1"] . "<br />" . $row["RelatedLink2"].
Although I do have much more control with this implementation, I think I am creating a big overhead in the table.
What is an efficient way to achieve this functionality?
EDIT
Referring to Gabriel's answer, the question now is about complexity:
With the current implementation, once I select the person I have all the links in my hand - complexity of O(1). What will be the complexity of running a query to select all foreign keys of the current Person, as suggested by Gabriel (and Haim) below?
Thanks,
Joel
If you only want to store and display the links, and the edit actions are very few, the first option is the best one. In this case, you will have to save the new values on edit.
If you think you'll have more edit operations, you could try to create a second tabel, to contain id_pearson, link, text, order . And you can use this tabel to edit the links for a specific pearson.
Also, if you need the same link for two or more persons, it's preferable to use 3 tables.
persons table : id_person, name (and all other info)
links table : id_link, text, link
person_links : id_person, id_link, order
Using this setup, you can edit the links in one place, and all persons will have access to the same version.
LATER EDIT IN RESPONSE TO COMMENT
Okey, regarding complexity of operations, nothing could beat the first solution. But you must take in account several things regarding what you need:
how often do you expect to change the links ?
who is gone change the links (the admin of the site, or the end user) ?
how many cases of the same link to appear for different persons (using the first solution, you will have to edit all persons that contain that link )
To answer your question of complexity, the solutions proposed by me are O(n) if I'm not mistaking. Using foreign keys and proper indexing in MySql, you shouldn't have a problem with this.
Summary: if performance is very important to you and the links will be edited only by the admin, use the first solution. If not, I would use the third one.
Hope this helps,
Gabriel
You need a secondary table that contains a PersonID (foreign Key), RelatedLink(ID) and maybe an OrderID.
Something like
Table PersonRelatedLinks
PersonID
RelatedLink or RelatedLinkID
OrderID
SpecialFormat maybe
I'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.