Why not have the manage app versions page work the same as the manage special users page with an update button per app version?
Jon Sonntag On Thu, Jun 27, 2013 at 4:48 AM, Bernd Machenschalk < [email protected]> wrote: > Hi! > > Recently the manage_app_versions.php suddenly messed up our app_version > table. All 'deprecated' flags together with all min and max client version > specifications were gone (i.e. set to 0). Work was sent out with app > versions it was never meant to be. The damage couldn't be repaired using > this same page. I spent half a night to manually fix the table in the DB. > > This could happen to every unsuspecting project at an unforeseeable time, > leaving no obvious way to fix it. > > Here's why: > > - the form in the page builds a POST string containing elements for ALL > rows in the app_versions table, i.e. the size of the POST string grows with > the table length > - of course the length of the POST buffer is limited (in the Apache > configuration IIRC) > - the current way the POST string is interpreted has no way to distinguish > between a value of zero and a value not being given at all. > > Consequently all values that are missing e.g. because of a truncated POST > string are assumed to be 0 and entered in the DB as such. As there is no > way to shorten the POST string, there is not even a way to correct such > errors using that page. > > For us this happened with 436 app versions in the table, but this number > is really arbitrary. The length of the (resulting) POST string e.g. depends > on how many of these versions are (already) deprecated. > > Most of our app versions relate to older apps that are now deprecated. So > for us and for now the quick workaround was to skip the versions of > deprecated apps (patch 0001), both when showing the list and when > processing the form. This, however, is dangerous: It relies on the > 'deprecated' status not changing between these two queries: when the list > to be shown is built and when the updates are performed. > > In order to prevent the page from completely messing up the table, I added > a small check for 'completeness' of the POST string (patch 0002). This adds > a hidden element (presumably) at the end of the POST string and prevents > any updates from being executed when this end tag didn't make it through. > > All of these measurements, however, don't really fix the root problem. To > do that one would need to rewrite the whole mechanism how the information > which updates are to be performed is passed. I don't really have time for > this now, maybe someone else has. > > Best, > Bernd > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
