How can I copy or move a complete package into another package?

Question

Question

Michael Steffen · Apr 12, 2022

#Caché

Hi,

i have made a testing package (name "test.a") and want to move it now into an other new package (f.example work.a)

is that possible?

Michael

Product version: Caché 2018.1

Discussion (3)2

Log in or sign up to continue

Evgeny Shvarov · Apr 12, 2022

I suppose your code is in some repository, e.g. GitHub, GitLab or Bitbucket. So you can just do the class rename code-refactoring procedure in all the classes of the package and in all the places the methods of package class can be called: rename code test.a->work.a.

and move all the files from folder test.a to work.a.

1 0

score 1 · Answer 1 · 2022-04-20T07:52:31-04:00

Hello Michael,

just export your classes into one XML file.
Open it with your favourite text-editor and use Find & Replace to change the Package Name of your classes.

Import it again. If you replaced correct, you'll find your new classes.

HTH Florian

score 0 · Answer 2 · 2022-04-21T12:22:55-04:00

I've used this approach before and it generally works fine, but there are some additional things to consider:

1) If your code contains SQL that references tables within the package you're renaming, you need to find/replace the schema as well as the package name. E.g., package my.demo would be schema my_demo. If you don't do this the SQL in your new package will reference the tables in your old package.

2) If you have Persistent classes in your package, you'll likely want to export with the /skipstorage qualifier. That will cause export to omit storage maps, so that the new package gets new storage maps and new globals when you compile. If you don't do this your new package might use the same globals as the old one because find/replace wouldn't change compressed global names like ^package.foobar9876.Class1D.

3) If you follow the previous suggestion, you may run into another problem if you try to copy your old globals to the new ones, so that you're bringing forward your data a well as code into the new package. The issue is that the new storage map will have all properties in the order they're declared. If you've added properties over time to the original class they may be in a different order, making the storage maps incompatible. That happens because new properties are always added at the end of an existing storage map, regardless of where they're declared. That prevents the need to convert data to a new structure if new properties are added to a deployed class. In that case you'll need to manually fix the new storage map by copying forward the old <Value> tags, while retaining the new global references.