Timeline for Features - branch 2.x results in large info files that exceed the 'info' column limit in the 'system' table
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13, 2013 at 15:42 | comment | added | wizonesolutions |
My system.info is already a LONGBLOB and I'm encountering this. It's probably my MySQL max_packet_size I guess?
|
|
| Aug 2, 2013 at 9:29 | comment | added | user5005 | Yeah I know the practice, I'd avoid it as well. I am only proposing since it seems like a small change that should not break anything or get reverted with any update. Anyway, thanks for your information, I'll spend the rest of the day testing tracking methods it seems. Configuration Management scares me a bit due to low installations and alpha versions but I'll give it a shot. | |
| Aug 2, 2013 at 9:14 | comment | added | Chapabu |
I would be super wary changing things in the system table. In fact, changing stuff like that on any contrib/core module table seems dodgy to me. Say the next update to core changes that table in some way...your change will be lost, and your site will break.
|
|
| Aug 2, 2013 at 9:12 | comment | added | Chapabu | It shouldn't matter. If something gets reverted that depends on something else, it should move to "Needs Review" in the Feature UI. Before you get a chance to notice this, the other Features should have also reverted and everything should be fine. I've used this approach before (broken down Feature that has managed to creep up in size), and the reverts were always fine. Any that weren't usually just needed another revert to prod it in the right direction. | |
| Aug 2, 2013 at 9:11 | comment | added | user5005 |
Also, do you reckon option 1 could break anything in the process? Is there any drawback on having the info collumn with increased size?
|
|
| Aug 2, 2013 at 9:08 | comment | added | user5005 | Regarding your features break-down approach. My problem is pretty much the order in which i'll have to run the reverts on the new environment, not the dependencies per say. I mean if Feature A contains vocabularies that are used by fields declared in Feature B and C, and you revert B first, you might mess everything up. The "sub" features will need to be constructed in a way that will allow for a specific revert order, right? | |
| Aug 2, 2013 at 8:59 | history | answered | Chapabu | CC BY-SA 3.0 |