I checked in this change.
-- David
On 27-Jun-2013 6:48 AM, Jon Sonntag wrote:
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.
_______________________________________________
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.
