Transport Package Question

SPForm creates a couple of resources on install.

I don’t want to overwrite them on upgrade, so UPDATE_OBJECT = false for them.


If the user changes the pagetitles of the resources, however, an upgrade creates two new ones.

I have UNIQUE_KEY set to pagetitle. Would setting it to ’id’ solve this?

I can move the creation of the resources to the script resolver and skip it for updates, but it would be a pain because of the housekeeping involved (I’d have to uninstall them without knowing their names, among other things), so I’m wondering if there’s an easier way.

Quote from: BobRay at Aug 10, 2011, 01:29 AM

I have UNIQUE_KEY set to pagetitle. Would setting it to ’id’ solve this?

No, as the ID will be different per installation, since it’s auto_increment.

I usually do ’alias’ for resources, but tbh, packaging Resources is painful at the moment. What it really needs is some sort of UUID.

Yes, agreed, this would help with lots of problems IMHO, we’ve already been here once with UUID’s albeit in the moving from staging to production arean, http://modxcms.com/forums/index.php?topic=51114

Quote from: splittingred at Aug 10, 2011, 08:02 AM

Quote from: BobRay at Aug 10, 2011, 01:29 AM

I have UNIQUE_KEY set to pagetitle. Would setting it to ’id’ solve this?

No, as the ID will be different per installation, since it’s auto_increment.

I usually do ’alias’ for resources, but tbh, packaging Resources is painful at the moment. What it really needs is some sort of UUID.

I’m afraid that won’t help. Anyone who changes the pagetitle will probably change the alias as well. UUIDs are definitely the way to go, but it may be tricky making the transition to having them.

In the meantime, the only solution I can think of is to install the resources in the PHP resolver and save their IDs in a file. I can check for the file before installing them and use the IDs from the file when removing them during the uninstall. It’s kind of ugly, but it should work.

Will $resource->remove() also remove children of the resource and any templateVarTemplates for the the resource or its children?

Unfortunately, unless we want to build links using UUID’s, which I don’t think we do, adding a UUID doesn’t really do anything to help resolve all the problems. Though you would be able to identify and remove the Resources you added, it would not help in remapping any links dependent on the ID’s, nor would it be much use if someone re-purposed the Resource you added. Consider someone not using something they installed but re-purposing that Resource for something else. When they uninstall the component they don’t use anymore, they lose their re-purposed Resource. There are a number of other issues related to this, but we are researching the best way to "resolve" these issues without having to write custom resolvers. UUID’s may be the answer, but that answer is not yet a solution which can be implemented.

Consider someone not using something they installed but re-purposing that Resource for something else. When they uninstall the component they don’t use anymore, they lose their re-purposed Resource.

OK, but this would occur whether you used UUID’s or not as you say, if someone does this then the uninstaller must somehow recognise that the resource has changed(re-purposed) and ignore it on the uninstall(hash value as how git does this maybe). Then of course there are situations where the installed resource is meant to be customised, so it will change, leading to allowing packagers to mark resources, templates etc. as ’do not remove on uninstall’. A complicated area that UUID’s may or may not help with but this is by no means the only situation where UUIDS can help.

Adding a UUID column to resources(and anything else for that matter) is trivial and generating one on creation is also trivial, once done people will find ways to use this data probably in novel ways that may not be envisaged or in fact needed at this time. I still believe adding UUID’s to database entities would be a good thing for Revo.

Quote from: shamblett at Aug 11, 2011, 01:33 PM

Consider someone not using something they installed but re-purposing that Resource for something else. When they uninstall the component they don’t use anymore, they lose their re-purposed Resource.

OK, but this would occur whether you used UUID’s or not as you say, if someone does this then the uninstaller must somehow recognise that the resource has changed(re-purposed) and ignore it on the uninstall(hash value as how git does this maybe). Then of course there are situations where the installed resource is meant to be customised, so it will change, leading to allowing packagers to mark resources, templates etc. as ’do not remove on uninstall’. A complicated area that UUID’s may or may not help with but this is by no means the only situation where UUIDS can help.

Adding a UUID column to resources(and anything else for that matter) is trivial and generating one on creation is also trivial, once done people will find ways to use this data probably in novel ways that may not be envisaged or in fact needed at this time. I still believe adding UUID’s to database entities would be a good thing for Revo.

It really is not trivial, yet, because each time you create a package, it would create a different UUID, unless we forced all packages to be built from existing data objects and you never changed the Resource the package was pulling from. Or we would have to hardcode UUIDs into the package scripts that created the Resource. But my point is there are a lot of issues around packaging Resources and other Revo objects, but remapping of keys used in links and other dependencies is still the biggest challenge and required whether we add UUID’s or not. References to the ID will exist everywhere from Template, Chunk and TV content to Property Set and System Setting values.

Are we talking about UUIDs for packages, or for objects created by packages? Are we contemplating a UUID column in the DB for system settings, menu items, etc. in addition to resources and elements?

It sounds like I better get to work on the custom resolver.

And can I get an answer to this:

Will $resource->remove() also remove children of the resource and any templateVarTemplates for the the resource or its children?

Quote from: BobRay at Aug 11, 2011, 05:04 PM

Are we talking about UUIDs for packages, or for objects created by packages? Are we contemplating a UUID column in the DB for system settings, menu items, etc. in addition to resources and elements?

Vehicle objects already have UUIDs, this discussion is about adding them to all the tables so objects could be mapped without dependence on remapping the primary keys. My inclination at this point is to maintain a separate table of UUIDs mapped to local primary keys, rather than adding them to every table. The only real issue then is how to generate the same UUID for the new objects when you rebuild packages if they are not coming from the database (IOW creating the objects with newObject vs. getObject/Collection).

Quote from: BobRay at Aug 11, 2011, 05:04 PM

Will $resource->remove() also remove children of the resource and any templateVarTemplates for the the resource or its children?

It should remove the modTemplateVarTemplate records, but Parents and Children are not related as composites so they will not automatically be removed. This is so processors can support various approaches to handling deletion, from simply removing the Children to presenting an interactive dialog to allow remapping of the Children to another Parent.

Thanks.

Wouldn’t there be an issue with different transport packages that use the same objects. A number of packages use Captcha, for example.