On 20.04.2010 12:33, sunew wrote:
In getpaid.core.options, the PersistentOptions class, used for
handling the annotation storage on objects, for items as well as
payment processors and so on, was setting the annotation_key on the
PersistentOptions class itself instead of the generated storage
classes (like BuyableContentStorage).
...
In my case everything ends up being stored under
getpaid.content.variableamountdonate, which is the last content
storage in Products.PloneGetPaid.content. My payment processor
apparently gets imported earlier, also getting this key for storage.
(a print statement in the PersistentOptions. wire class method reveal
the order).
Well, if it's always the case that everything gets stored under a single
specific key, isn't it then enough to find that key (possibly
installation dependent) and copy properties (for all known
keys/interfaces) under known correct keys.
So, for every payable:
1. iterate through all existing annotation keys
2. pick the PersistentOptions key, which has the most stored options *)
3. store those annotations (key, value -pairs) temporarily
4. iterate through all known PersistentOptions key/interface-pairs
5. if an interface can be imported, store its annotations with
respective annotation key (only if proper key, value -pairs were
retrieved earlier)
*) I guess, it's possible that there still are annotations with more
than one PersistentOptions key. In those sitatiuations, the key with
most options is probably the used one.
Well, to avoid side effects, for particular markers it could be checked
if the marker currently exist for the current payable before storing
options with the markers annotation key.
Most of the general setup is now based on a utility, see
Products.PloneGetPaid.preferences.
So, then only payment processor options are stored as annotations (and
affected by this bug; actually, as you already wrote earlier :)
Would you still use Products.PloneGetPaid's custom upgrading framework
for a such migration or should it be done as GenericSetup upgradeStep?
I havent looked at the getpaid upgrading stuff, I guess GenericSetup
would be my prefered choice.
With GenericSetup upgradeStep it may be a problem that PloneGetPaid's
version has been reflected to GS profile-version (on metadata.xml). The
upgradeStep must be from a specific profile version to an another
specific profile version. Since the installed PloneGetPaid-profile
version is usually only updated when PloneGetPaid is either installed or
re-installed, there probably exists installations where installed
PloneGetPaid-profile version is lesser than version of the the used
PloneGetPaid-product.
Technically, both migration options probably require as much work.
Best Regards,
Asko
--
GetPaid for Plone: http://www.plonegetpaid.com (overview info) |
http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups
"getpaid-dev" group.
To post to this group, send email to getpaid-dev@googlegroups.com
To unsubscribe from this group, send email to
getpaid-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
