Why does JCB change two column sizes of the #__assets table? #616

New Issue

Closed

opened 2020-11-24 11:23:49 +00:00 by brianteeman · 9 comments

brianteeman commented

2020-11-24 11:23:49 +00:00

(Migrated from github.com)

Steps to reproduce the issue

Install component builder

Expected result

Component Installed

Actual result

The core database table #__assets has its structure changed

https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/sql/install.mysql.utf8.sql#L2434-L2441

Additional comments

This is wrong in so many ways - I am speechless

### Steps to reproduce the issue Install component builder ### Expected result Component Installed ### Actual result The core database table #__assets has its structure changed https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/sql/install.mysql.utf8.sql#L2434-L2441 ### Additional comments This is wrong in so many ways - I am speechless

Llewellyn commented

2020-11-24 20:42:58 +00:00

We both are speechless... so lets talk.

Resolving this issue five years ago was not possible, and today it is not that simple, or straightforward. I was simply at the time unwilling to wait for Joomla, no one took me seriously when I asked for this change (not that I blame them..), but today I know the current team better, and probably we can fix this is some way or another.

Simple fact is JCB can build large permission structures per/component that are to large for the current column size, take this one that is public for example:
https://github.com/Llewellynvdm/Joomla-Cost-Benefit-Projection/blob/master/admin/access.xml

So when you save that permissions structure, the JSON gets truncated and the permissions break. Yet, that is still a small one... I have a number of projects where that is far larger. SO yes, I know the permission structure itself is the pain... and enlarging the column does not fix the problem. But for me and many other it did allow us the freedom we need, and we will probably continue this way until Joomla improves this area.

That is the power of JCB every time you compile a component, it gets written from the ground-up and so introducing changes, and fixes are much faster, and easier to navigate. Fix JCB and you fix 5000+ extensions, of which 200 is just my own.

I think very few have realized what JCB has done, and is doing...

Listen Brian as side note, please remember that JCB was the third component I ever wrote for Joomla. Here is the first https://github.com/namibia/CBP-Joomla-2-Component and here is the second https://github.com/getbible/Joomla-3-Component
Back then I knew very little and yet achieved what everyone at the time thought was impossible. Today when I look at JCB "the compiler" I want to rewrite it completely and I can see much room for improvements, I know I did not follow good practice, but I am not ashamed of what I did, it is still brilliant and the components it builds are stable.

Giving a notice that we changed this table could be an improvement, but removing the change on uninstall of the component could cause issues, since there could be more then one component installed that needs this larger column, and reverting the change when the one component is uninstalled will cause the other to break.

Now I know the point of breaking the component up in smaller components is the current best practice, but I do not what to add that limitation forcefully to JCB, but I do give notice of this when tables go over 50 fields. We could add more notices... yet why not just enlarge the column, so I will go back to Joomla and see if they are willing.

We both are speechless... so lets talk. Resolving this issue [five years](https://github.com/vdm-io/Joomla-Component-Builder/blame/1312e45d4a7c93917d616f9c2a9d56f18ae72f74/admin/compiler/joomla_3/install.mysql.utf8.sql) ago was not possible, and today it is not that simple, or straightforward. I was simply at the time unwilling to wait for Joomla, no one took me seriously when I asked for this change (not that I blame them..), but today I know the current team better, and probably we can fix this is some way or another. Simple fact is JCB can build large permission structures per/component that are to large for the current column size, take this one that is public for example: https://github.com/Llewellynvdm/Joomla-Cost-Benefit-Projection/blob/master/admin/access.xml So when you save that permissions structure, the JSON gets truncated and the permissions break. Yet, that is still a small one... I have a number of projects where that is far larger. SO yes, I know the permission structure itself is the pain... and enlarging the column does not fix the problem. But for me and many other it did allow us the freedom we need, and we will probably continue this way until Joomla improves this area. That is the power of JCB every time you compile a component, it gets written from the ground-up and so introducing changes, and fixes are much faster, and easier to navigate. Fix JCB and you fix 5000+ extensions, of which 200 is just my own. I think very few have realized what JCB has done, and is doing... > Listen Brian as side note, please remember that JCB was the **third component I ever wrote for Joomla**. Here is the first https://github.com/namibia/CBP-Joomla-2-Component and here is the second https://github.com/getbible/Joomla-3-Component > Back then I knew very little and yet achieved what everyone at the time thought was impossible. Today when I look at JCB "the compiler" I want to rewrite it completely and I can see much room for improvements, I know I did not follow good practice, but I am not ashamed of what I did, it is still brilliant and the components it builds are stable. Giving a notice that we changed this table could be an improvement, but removing the change on uninstall of the component could cause issues, since there could be more then one component installed that needs this larger column, and reverting the change when the one component is uninstalled will cause the other to break. Now I know the point of breaking the component up in smaller components is the current best practice, but I do not what to add that limitation forcefully to JCB, but I do give notice of this when tables go over 50 fields. We could add more notices... yet why not just enlarge the column, so I will go back to Joomla and see if they are willing.

brianteeman commented

2020-11-25 22:03:20 +00:00

(Migrated from github.com)

I am going to try and answer this in multiple parts.

1. Dont hack the core

The change you are making to core files should never be done. No extension should ever touch any of the core files ever. And yes changing the structure of a core database table is hacking the core

By hacking the core you have done a disservice to your users and their users. Joomla may contain updates the core database tables and you have just broken that and potentially broken their sites during an update. In the recent past we have had updates to address utf8 and with joomla 3.10 and 4 to address null values. These updates have of course been written on the assumption of a known database structure.
Yay you just broke it. Guess who will get the blame and who will have their reputation damaged - it won't be you.

2. Don't hide the hacks

Perhaps its just my inquisitive mind but I always look at changelogs and that's where I saw a hint at this hack. There is no mention of it anywhere in the documentation or installation notes.

3. Clean up after yourself

When I uninstall an extension I expect it to remove everything it did when it was installed. Some extensions might leave any data tables but they will often inform you of that. You have an uninstall sql but it does not revert the hack to the database. It will stay there forever or until a joomla update breaks the site.
Yay you just broke it. Guess who will get the blame and who will have their reputation damaged - it won't be you.

4. Performance

There is a massive performance difference between a varchar (512) and a mediumtext ref High Performance Mysql. So now not only do you not clean up after yourself but you are degrading the performance of every joomla web site that ever tried your code. To be clear the change has impact on the entire web site not just your code.
Yay you just broke it. Guess who will get the blame and who will have their reputation damaged - it won't be you.

5. Code

It doesnt matter if this is your 1st or 90th component. This is wrong and you should change it. Having an ACL rules table with 1000 options is crazy crazy crazy (see image below)

6. You don't need it

Now I get to wondering why you even need the change. The column in the database only stores the acl rules that are changed - it doesn't save every single one of the 1000 rules it just saves the changes you just made.

So yes it is a big deal. I really don't care what people do in their own code. I care what people do that impacts the joomla code. This hack of yours has a serious impact on any joomla site it comes into contact with. Like all infections, the hack needs to be eliminated as a priority.

Llewellyn moved the image so the thread is shorter to read, since yes it is a very large image.... 👍

https://imgur.com/QFLgnG0

I am going to try and answer this in multiple parts. ## 1. Dont hack the core The change you are making to core files should never be done. No extension should ever touch any of the core files ever. And yes changing the structure of a core database table is _hacking the core_ By hacking the core you have done a disservice to your users and their users. Joomla may contain updates the core database tables and you have just broken that and potentially broken their sites during an update. In the recent past we have had updates to address utf8 and with joomla 3.10 and 4 to address null values. These updates have of course been written on the assumption of a known database structure. **_Yay you just broke it. Guess who will get the _blame_ and who will have their reputation damaged - it won't be you._** ## 2. Don't hide the hacks Perhaps its just my inquisitive mind but I always look at changelogs and that's where I saw a hint at this hack. There is no mention of it anywhere in the documentation or installation notes. ## 3. Clean up after yourself When I uninstall an extension I expect it to remove everything it did when it was installed. Some extensions might leave any data tables but they will often inform you of that. You have an uninstall sql but it does not revert the hack to the database. It will stay there forever or until a joomla update breaks the site. **_Yay you just broke it. Guess who will get the _blame_ and who will have their reputation damaged - it won't be you._** ## 4. Performance There is a massive performance difference between a varchar (512) and a mediumtext ref [High Performance Mysql](https://www.oreilly.com/library/view/high-performance-mysql/9781449332471/ch04.html). So now not only do you not clean up after yourself but you are degrading the performance of every joomla web site that ever tried your code. **To be clear the change has impact on the entire web site not just your code.** **_Yay you just broke it. Guess who will get the _blame_ and who will have their reputation damaged - it won't be you._** ## 5. Code It doesnt matter if this is your 1st or 90th component. This is wrong and you should change it. Having an ACL rules table with **1000** options is crazy crazy crazy (see image below) ## 6. You don't need it Now I get to wondering why you even need the change. The column in the database **only** stores the acl rules that are changed - it doesn't save every single one of the 1000 rules it just saves the changes you just made. So yes it is a big deal. I really don't care what people do in their own code. I care what people do that impacts the joomla code. This hack of yours has a serious impact on any joomla site it comes into contact with. Like all infections, the hack needs to be eliminated as a priority. ### Llewellyn moved the image so the thread is shorter to read, since yes it is a very large image.... :+1: https://imgur.com/QFLgnG0

Llewellyn commented

2020-11-26 01:04:06 +00:00

Thank you for all the valuable information you shared... very helpful.

Hope you understand that I stand by my change to the asset table that it is needful at times, as a temporary fix 5 years ago with the hope that it will serve as a simple work around until Joomla improves this area, which they must do and hopefully will soon.

Even though I don't agree with all you said... and somethings I will just ignore.

I have seen a solution that could possibly be the only amicable path forward where we remove the automatic change, and let you the developer choose which path you want to take, and it seems like there are three paths. I will share more here soon...

I am working on moving the filters above the list views at the moment, and when that is done, I will take this next.

Thank you for all the valuable information you shared... very helpful. Hope you understand that I stand by my change to the asset table that it is needful at times, as a temporary fix 5 years ago with the hope that it will serve as a simple work around until Joomla improves this area, which they must do and hopefully will soon. Even though I don't agree with all you said... and somethings I will just ignore. I have seen a solution that could possibly be the only amicable path forward where we remove the automatic change, and let you the developer choose which path you want to take, and it seems like there are three paths. I will share more here soon... I am working on [moving the filters](https://github.com/vdm-io/Joomla-Component-Builder/issues/378) above the list views at the moment, and when that is done, I will take this next.

brianteeman commented

2020-11-29 12:10:15 +00:00

(Migrated from github.com)

Disappointed that you changed the title to try and hide the severity of the issue

Llewellyn commented

2020-12-01 17:08:08 +00:00

To anyone who comes this way, we have added the uninstall revers code to the default JCB path, and we will soon add more GUI options to control this, I will continue to link this ticket to any related changes.

To anyone who comes this way, we have added the [uninstall revers code](https://github.com/vdm-io/Joomla-Component-Builder/commit/4339ca00b3232cdf572d9aa93f3f84146f007305#diff-2a579406db2e87b6a65bf2ff2ef328f0fabb9a5833e8e6bcf4518209bb9a4893R53) to the default JCB path, and we will soon add more GUI options to control this, I will continue to link this ticket to any related changes.

Llewellyn commented

2020-12-09 03:29:13 +00:00

The conclusion

Okay, so I finally had time to research this issue more and the Joomla column is now varchar(5120)
The var char size limit is based on the row limit which is about 65535 var chars. This basically means that Joomla is not close to the limit yet with the varchar(5120), yet I was told that Joomla does not plan to enlarge this any time soon.

So why do they insist to use the varchar instead of text, or medium text like JCB does? (which is no big deal at all) Basically they say since varchar is stored in the row array and not at another location in memory, so it has a fractional faster access. So how much faster is this access? Well in this old article there seems to be very little difference whatsoever. Honestly this whole issue seems to result in debates with strong options on both sides of the fence, and clearly the benchmarks made differ seemingly due to many factors not even related to the issue.

You see the point made is not that the table is larger (since to this I/we would agree, I mean we need it to be larger to hold or larger json object)... no their point is that the table performs slower, but that is just not true. Your TEXT or MEDIUMTEXT works by pointers... and pointers are the very power of C and C++ and what gives those languages the speed we all long for in other higher level languages like PHP.

The facts!

So what facts do we have... 30 actions in the access permissions of a component is enough to push up against the current limit of varchar(5120). You see each action with a length of +-20 characters and the normal 8 groups while you set each group independently with very little inheritance, then we get 4800 characters (20x30x8=4800). To get 30 actions in a component is very easy, most components in JCB with moderate use of permissions have around 100 actions if the component has 10 views, JCB itself has 54 views which gives us 543 actions, you do the math... that is 86880 characters in WORSE case. What is worse case? Glad you asked, worse case as I explained before is when you set each group independently with very little inheritance, then you get worse case.

So in JCB we have now added the following options as the current solution.

We cannot wait for Joomla since most normal users will never have these needs, unless they use our advanced components, therefore we need to fix this with JCB. So until Joomla sets a better solution on the table this is how I think we can do this.

We added a global and per/component switch to allow you to control the outcome.

SQL (add&remove) this is the default which adds the SQL fix and removes it once the component is uninstalled.

Intelligent (add&remove+if) same as default, but on uninstall will only remove this fix if no other component needs it. Note that this option will only work with other components that also use the intelligent path.

This means you have three options

Never add the access table fix ever.
Add the fix only if needed (more then 30 actions) which adds the SQL fix and removes it once the component is uninstalled (this is also the default)
Add the fix only if needed just like the default but with intelligent removal. This means if the component gets uninstalled and detects another component also needs the fix, it will not remove it.

I will push the code for this very soon as part of the v2.12.2 release due this week.

# The conclusion Okay, so I finally had time to research this issue more and the Joomla column is now [varchar(5120)](https://github.com/joomla/joomla-cms/blob/3.9.23/installation/sql/mysql/joomla.sql#L22) The var char size limit is [based on the row limit](https://www.mysqltutorial.org/mysql-varchar/) which is about 65535 var chars. This basically means that Joomla is not close to the limit yet with the [varchar(5120)](https://github.com/joomla/joomla-cms/blob/3.9.23/installation/sql/mysql/joomla.sql#L22), yet I was told that [Joomla](https://volunteers.joomla.org/teams/cms-maintenance-team) does not plan to enlarge this any time soon. So why do they insist to use the varchar instead of [text, or medium](https://stackoverflow.com/a/15227917/1429677) text like JCB does? ([which is no big deal at all](https://stackoverflow.com/a/15227917/1429677)) Basically they say since varchar is stored in the row array and not at another location in memory, so it has a fractional faster access. So how much faster is this access? Well in this [old article](https://forums.mysql.com/read.php?24,105964,105964) there seems to be very little difference whatsoever. Honestly this whole issue seems to result in debates with strong options on both sides of the fence, and clearly the benchmarks made differ seemingly due to many factors not even related to the issue. You see the point made is not that the table is larger (since to this I/we would agree, I mean we need it to be larger to hold or larger json object)... no their point is that the table performs slower, but that is just not true. Your TEXT or MEDIUMTEXT works by pointers... and pointers are the very power of C and C++ and what gives those languages the speed we all long for in other higher level languages like PHP. ### The facts! So what facts do we have... 30 actions in the access permissions of a component is enough to push up against the current limit of [varchar(5120)](https://github.com/joomla/joomla-cms/blob/3.9.23/installation/sql/mysql/joomla.sql#L22). You see each action with a length of +-20 characters and the normal 8 groups while you set each group independently with very little inheritance, then we get **4800 characters** _(20x30x8=4800)_. To get 30 actions in a component is very easy, most components in JCB with moderate use of permissions have around **100 actions** if the component has 10 views, JCB itself has 54 views which gives us 543 actions, you do the math... that is **86880 characters in WORSE case**. What is worse case? Glad you asked, worse case as I explained before is when you set **each group independently** with very little inheritance, then you get worse case. ### So in JCB we have now added the following options as the current solution. We cannot wait for Joomla since most normal users will never have these needs, unless they use our advanced components, therefore we need to fix this with JCB. So until Joomla sets a better solution on the table this is how I think we can do this. We added a **global and per/component** _switch_ to allow **you** to control the outcome. ![image](https://user-images.githubusercontent.com/5607939/101569161-9a585280-39dc-11eb-8b87-51df41859c14.png) > SQL (add&remove) this is the default which adds the SQL fix and removes it once the component is uninstalled. Intelligent (add&remove+if) same as default, but on uninstall will only remove this fix if no other component needs it. Note that this option will only work with other components that also use the intelligent path. This means you have three options - Never add the access table fix ever. - Add the fix only if needed (more then 30 actions) which adds the SQL fix and removes it once the component is uninstalled (this is also the default) - Add the fix only if needed just like the default but with intelligent removal. This means if the component gets uninstalled and detects another component also needs the fix, it will not remove it. I will push the code for this very soon as part of the v2.12.2 release due this week.

Llewellyn commented

2020-12-10 23:16:11 +00:00

Just to validate that LENGTH AND CHAR_LENGTH is generally the same.

Since we are working with a json object that is normally only build-up of ISO basic Latin alphabet these two values of the string length and the char length is normally therefore the same.

Also note that when we set a column length to MEDIUMTEXT, it does not USE that much space for each row!

This is an assumption that is made by those who do not understand how smart MySql really is. Here you can read more about this in the manual. But basically the TEXT type data structure only use what it needs per row, and not bigger then the type selected. The TEXT type is 65,535 bytes ~64kb and for the MEDIUMTEXT is 16,777,215 bytes ~16MB. We have seen in a worse case a component can have more then 65535 characters, and that is why we used MEDIUMTEXT since we know MySql will only use what it needs per row and will not bloat the table, or massively impact the performance of the table.

Further more we understand that "text" and "varchar" is not the same thing.

Yet we often see that 1 byte may hold 1 character, except with multi-byte characters. Which then does indeed make the length of a string not always the same as the number of bytes we would need based on the Server/DB/Table charset being UTF-8 Unicode (utf8mb4) or something else. But all that this means is that a 50 character string (which may have multi-bytes) could need 80 bytes of space. So in our case working with the string length to detect the length required is the safe option. Since if a string can be more than 5120 characters it will not be less bytes, just more. Now even more for the benefit of all those who is following this tread we are in the assets rule column just working with a json object that is normally only build-up of ISO basic Latin alphabet. This means we very often will see the char length and the string length be the same, like seen above.

## Just to validate that LENGTH AND CHAR_LENGTH is generally the same. Since we are working with a json object that is normally only build-up of **ISO basic Latin alphabet** these two values of the string length and the char length is normally therefore the same. ![image](https://user-images.githubusercontent.com/5607939/101837802-4b2f3080-3b48-11eb-84f4-9f8f51e3787e.png) ![image](https://user-images.githubusercontent.com/5607939/101837868-639f4b00-3b48-11eb-8e28-b080c67646e2.png) ![image](https://user-images.githubusercontent.com/5607939/101838022-99dcca80-3b48-11eb-9432-66c4dc5200f7.png) ![image](https://user-images.githubusercontent.com/5607939/101838091-b416a880-3b48-11eb-8657-d22be4fcf33b.png) ### Also note that when we set a column length to MEDIUMTEXT, it does not USE that much space for each row! This is an assumption that is made by those who do not understand how smart MySql really is. Here you can read more about this in [the manual](https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html). But basically the TEXT type data structure only use what it needs per row, and **not bigger then the type** selected. The TEXT type is 65,535 bytes ~64kb and for the MEDIUMTEXT is 16,777,215 bytes ~16MB. We have seen in a worse case a component can have more then 65535 characters, and that is why we used MEDIUMTEXT since we know MySql will only use what it needs per row and will not bloat the table, or massively impact the performance of the table. ### Further more we understand that "text" and "varchar" is not the same thing. Yet we often see that 1 byte may hold 1 character, except with multi-byte characters. Which then does indeed make the length of a string not always the same as the number of bytes we would need based on the Server/DB/Table charset being [UTF-8](https://en.wikipedia.org/wiki/UTF-8) Unicode (utf8mb4) or something else. But all that this means is that a 50 character string (which may have multi-bytes) could need 80 bytes of space. So in **our case** working with the string length to detect the length required **is the safe** option. Since if a string can be more than **5120 characters** it will not be less bytes, just more. Now even more for the benefit of all those who is following this tread we are in the assets rule column just working with a json object that is normally only build-up of **ISO basic Latin alphabet**. This means we very often will see the char length and the string length be the same, like seen above.

Llewellyn commented

2020-12-11 02:21:48 +00:00

@vdm-io/jcb-core pease test the new Intelligent assets table fix, and let me know so we can push this smart update out 👍

First Test:

Compile JCB with the new staging branch
Install on new website
Check that you get the notice that the table was changed
Check that the table was indeed change
Uninstall JCB
Check that you get the notice that the table was reverted back to varchar(5120)
Check that the table was indeed change back.

Second Test:

Compile JCB with the new staging branch
Install on new website
Check that you get the notice that the table was changed
Check that the table was indeed change
Fill the asset table rules column of another component with more then 5120 characters... just for the test.
Uninstall JCB
Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger.
Check that the table was indeed NOT change back.

Third test:

Compile JCB with the new staging branch
Install on new website
Check that you get the notice that the table was changed
Check that the table was indeed change
Fill the asset table rules column of JCB component with more then 5120 characters... just for the test.
Compile another component that also has many permission access actions
Install on the same website as where JCB was installed
Check that you DO NOT get a message saying that any thing changed.
Check that the table was indeed NOT change
Uninstall the second component
Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger.
Check that the table was indeed NOT change back.
Uninstall JCB
Check that you get the notice that the table was reverted back to varchar(5120)
Check that the table was indeed change back.

I have tested this already and it all worked perfectly, let me know ;)

@vdm-io/jcb-core pease test the new Intelligent assets table fix, and let me know so we can push this smart update out :+1: First Test: - Compile JCB with the new staging branch - Install on new website - Check that you get the notice that the table was changed - Check that the table was indeed change - Uninstall JCB - Check that you get the notice that the table was reverted back to varchar(5120) - Check that the table was indeed change back. Second Test: - Compile JCB with the new staging branch - Install on new website - Check that you get the notice that the table was changed - Check that the table was indeed change - Fill the asset table rules column of another component with more then 5120 characters... just for the test. - Uninstall JCB - Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger. - Check that the table was indeed NOT change back. Third test: - Compile JCB with the new staging branch - Install on new website - Check that you get the notice that the table was changed - Check that the table was indeed change - Fill the asset table rules column of JCB component with more then 5120 characters... just for the test. - Compile another component that also has many permission access actions - Install on the same website as where JCB was installed - Check that you DO NOT get a message saying that any thing changed. - Check that the table was indeed NOT change - Uninstall the second component - Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger. - Check that the table was indeed NOT change back. - Uninstall JCB - Check that you get the notice that the table was reverted back to varchar(5120) - Check that the table was indeed change back. I have tested this already and it all worked perfectly, let me know ;)

Oh Martin commented

2020-12-11 07:05:40 +00:00

@vdm-io/jcb-core pease test the new Intelligent assets table fix, and let me know so we can push this smart update out +1

First Test:

* Compile JCB with the new staging branch

* Install on new website

* Check that you get the notice that the table was changed

* Check that the table was indeed change

* Uninstall JCB

* Check that you get the notice that the table was reverted back to varchar(5120)

* Check that the table was indeed change back.

Second Test:

* Compile JCB with the new staging branch

* Install on new website

* Check that you get the notice that the table was changed

* Check that the table was indeed change

* Fill the asset table rules column of another component with more then 5120 characters... just for the test.

* Uninstall JCB

* Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger.

* Check that the table was indeed NOT change back.

Third test:

* Compile JCB with the new staging branch

* Install on new website

* Check that you get the notice that the table was changed

* Check that the table was indeed change

* Fill the asset table rules column of JCB component with more then 5120 characters... just for the test.

* Compile another component that also has many permission access actions

* Install on the same website as where JCB was installed

* Check that you DO NOT get a message saying that any thing changed.

* Check that the table was indeed NOT change

* Uninstall the second component

* Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger.

* Check that the table was indeed NOT change back.

* Uninstall JCB

* Check that you get the notice that the table was reverted back to varchar(5120)

* Check that the table was indeed change back.

I have tested this already and it all worked perfectly, let me know ;)

Tested successfully!

> @vdm-io/jcb-core pease test the new Intelligent assets table fix, and let me know so we can push this smart update out +1 > > First Test: > > * Compile JCB with the new staging branch > > * Install on new website > > * Check that you get the notice that the table was changed > > * Check that the table was indeed change > > * Uninstall JCB > > * Check that you get the notice that the table was reverted back to varchar(5120) > > * Check that the table was indeed change back. > > > Second Test: > > * Compile JCB with the new staging branch > > * Install on new website > > * Check that you get the notice that the table was changed > > * Check that the table was indeed change > > * Fill the asset table rules column of another component with more then 5120 characters... just for the test. > > * Uninstall JCB > > * Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger. > > * Check that the table was indeed NOT change back. > > > Third test: > > * Compile JCB with the new staging branch > > * Install on new website > > * Check that you get the notice that the table was changed > > * Check that the table was indeed change > > * Fill the asset table rules column of JCB component with more then 5120 characters... just for the test. > > * Compile another component that also has many permission access actions > > * Install on the same website as where JCB was installed > > * Check that you DO NOT get a message saying that any thing changed. > > * Check that the table was indeed NOT change > > * Uninstall the second component > > * Check that you get the notice that the table was NOT reverted back to varchar(5120) since another component still needs the column to be larger. > > * Check that the table was indeed NOT change back. > > * Uninstall JCB > > * Check that you get the notice that the table was reverted back to varchar(5120) > > * Check that the table was indeed change back. > > > I have tested this already and it all worked perfectly, let me know ;) Tested successfully!