On Sunday, September 22, 2024 2:32:31 P.M. CDT Stefano Crocco wrote: > Thanks for your answer. If I understand correctly what you mean, I think I > was aiming for a solution with slightly different results than yours: > - what I wanted was I migration from old to new entries which would solve > all ambiguities. Referring to the example above, from the http://xyz.com# > entry, I wanted to determine whether it referred to the form f1 or to the > form f2 and to create either the http://xzy.com#f1 or the http://xyz.com#f2 > entry but not both
Oh -- so you are looking for a one-time migration of all entries? If that's the case, I didn't understand it that way. > - what you are suggesting instead, is to keep the ambiguity by creating two > entries with the new names, one for each form, having the same contents. In > the example, this would mean creating both the http://xzy.com#f1 and the > http://xzy.com#f2 entries. Is this correct? I was building on the previous suggestion "Keep the old load code as a fallback to the new load code. You can drop the old save code, but the old load code probably has to be kept forever." The way I understood that suggestion is that there is NOT a one-time migration. Rather, the algorithm when encountering a page with forms is roughly: 1. look up the new way - if entry found, then use it; else 2. look up the old way - if entry found, then a) migrate to new storage b) use data to fill form So it would be a gradual migration. If the data is found under the old scheme, then for migration (Step 2a) I would think you have enough info to build an unambiguous key for the new scheme? So I don't think I'm suggesting to keep ambiguity by "creating two entries". Rather, I was imagining nothing happens until the next time the user hits the page and THEN migrate. I freely admit that I'm way out of my depth here. ;-) Regards, -Steve
signature.asc
Description: This is a digitally signed message part.
