Difference between revisions of "Insert error in menu table of migrated data"
From Joomla! Documentation
| (4 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
:Thanks Sovainfo. Yes, I broke it out of the Upgrading page. The pull request you referenced will make it into 3.2 and at that point it should be a non-issue for people upgrading to 3.2+ versions from 2.5. I see you also posted to the forum article where this came from originally. IMO, what we really need is a script to correct all the problems with the ids, move the user created ones and search for missing missing core menus. Thanks again. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 19:37, 16 August 2013 (CDT) | :Thanks Sovainfo. Yes, I broke it out of the Upgrading page. The pull request you referenced will make it into 3.2 and at that point it should be a non-issue for people upgrading to 3.2+ versions from 2.5. I see you also posted to the forum article where this came from originally. IMO, what we really need is a script to correct all the problems with the ids, move the user created ones and search for missing missing core menus. Thanks again. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 19:37, 16 August 2013 (CDT) | ||
Consider that the wrong solution! Stop abusing the rdbms. There should be no other meaning attached to the id. In relational speak, you need an attribute that contains that information. Combining information is not done in the relational world. Sofar I haven't seen any requirement for identifying cms delivered menuitems apart from user added menuitems. If there is, you need to add an attribute, not putting meaning in the sequence number. The solution is to remove the id from the column list and its value from the values list. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 03:03, 17 August 2013 (CDT) | Consider that the wrong solution! Stop abusing the rdbms. There should be no other meaning attached to the id. In relational speak, you need an attribute that contains that information. Combining information is not done in the relational world. Sofar I haven't seen any requirement for identifying cms delivered menuitems apart from user added menuitems. If there is, you need to add an attribute, not putting meaning in the sequence number. The solution is to remove the id from the column list and its value from the values list. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 03:03, 17 August 2013 (CDT) | ||
| + | :Before my time why the ids were hard coded in so I have no idea the thought behind it or the thought of why it was needed. We need to deal with what we have, how to fix the existing problems and then move forward. If you have a solution, I invite you to submit a pull request. Thanks [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 09:01, 17 August 2013 (CDT) | ||
| + | There is no need for another pull request. PR1722 solves it. At least when they stop using fixed numbers. That solution is also provided on the forum (just removing id from INSERT). So, there is no need for the procedure described in this document. Hopefully others will understand! [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 02:51, 18 August 2013 (CDT) | ||
| + | :Thanks Sovainfo. I thought there was an issue of the possibility of missing core item(s) too. I'll go back and reread everything. There was a tracker started spring of 2012 about the JUpgrade issues. The additional fix I was referring too was making sure all the core menu items were there and in place. IDs not important, just make sure the core items exist and if not add them in without the necessity of a specific ID. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 08:26, 18 August 2013 (CDT) | ||
| + | :Ah ha, I see now. There was a mention of script needed to move all non-core to above 200 in the forum post along with a repair to add in missing core items. Non issue really with the pull request. No need to move items above 200. A script to do so could cause a lot more issues if not careful. Core item check? That might be useful. Thanks again! [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 09:13, 18 August 2013 (CDT) | ||
| + | Indeed, feel very sorry for the person who wrote this. And for all the people that followed his advice. Including the writing of this article. It is a complete waste of time, provided they stop assigning id numbers. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 17:15, 18 August 2013 (CDT) | ||
Latest revision as of 17:15, 18 August 2013
Wouldn't waste time on this, see https://github.com/joomla/joomla-cms/pull/1722. Sovainfo (talk) 08:47, 16 August 2013 (CDT)
- Thanks Sovainfo. Yes, I broke it out of the Upgrading page. The pull request you referenced will make it into 3.2 and at that point it should be a non-issue for people upgrading to 3.2+ versions from 2.5. I see you also posted to the forum article where this came from originally. IMO, what we really need is a script to correct all the problems with the ids, move the user created ones and search for missing missing core menus. Thanks again. Tom Hutchison (talk) 19:37, 16 August 2013 (CDT)
Consider that the wrong solution! Stop abusing the rdbms. There should be no other meaning attached to the id. In relational speak, you need an attribute that contains that information. Combining information is not done in the relational world. Sofar I haven't seen any requirement for identifying cms delivered menuitems apart from user added menuitems. If there is, you need to add an attribute, not putting meaning in the sequence number. The solution is to remove the id from the column list and its value from the values list. Sovainfo (talk) 03:03, 17 August 2013 (CDT)
- Before my time why the ids were hard coded in so I have no idea the thought behind it or the thought of why it was needed. We need to deal with what we have, how to fix the existing problems and then move forward. If you have a solution, I invite you to submit a pull request. Thanks Tom Hutchison (talk) 09:01, 17 August 2013 (CDT)
There is no need for another pull request. PR1722 solves it. At least when they stop using fixed numbers. That solution is also provided on the forum (just removing id from INSERT). So, there is no need for the procedure described in this document. Hopefully others will understand! Sovainfo (talk) 02:51, 18 August 2013 (CDT)
- Thanks Sovainfo. I thought there was an issue of the possibility of missing core item(s) too. I'll go back and reread everything. There was a tracker started spring of 2012 about the JUpgrade issues. The additional fix I was referring too was making sure all the core menu items were there and in place. IDs not important, just make sure the core items exist and if not add them in without the necessity of a specific ID. Tom Hutchison (talk) 08:26, 18 August 2013 (CDT)
- Ah ha, I see now. There was a mention of script needed to move all non-core to above 200 in the forum post along with a repair to add in missing core items. Non issue really with the pull request. No need to move items above 200. A script to do so could cause a lot more issues if not careful. Core item check? That might be useful. Thanks again! Tom Hutchison (talk) 09:13, 18 August 2013 (CDT)
Indeed, feel very sorry for the person who wrote this. And for all the people that followed his advice. Including the writing of this article. It is a complete waste of time, provided they stop assigning id numbers. Sovainfo (talk) 17:15, 18 August 2013 (CDT)