Class storage definition in atelier

I am using Atelier + EGit plugins for a project. Is it possible to turn the storage definition off in Atelier so this does not get copied to Git when I make changes? While developing on different versions of the code on different systems, it may cause conflicts and excess noise in the source control history

  • 0
  • 0
  • 139
  • 4
  • 2

Answers

Yes, to skip exporting storage you need to specify compilation flag:

/skipstorage=1

Description

Name: /skipstorage
Description: In class Export, if true do not export storage definition.
Type: logical
Default Value: 0

You can set it:

  • System-wide
  • As a Namespace default
  • For Atelier only: Project -> Compile Configuration

System and namespace defaults could be set via:

Set sc = $System.OBJ.SetQualifiers(qualifiers, system)

Have you tested this and seen it work? I tried this before posting the question and it does not appear to work for me

Hi, Peter!

I would warn you of NOT including storage information in Git (or any other CVS).  It is the must to keep class storage definition within source control.

Consider you have a system in production where you have class A with properties P1 and P2 with data.

And you developed a new version of a product with the optimization when you don't need P1 anymore and delete it. And you added a new feature which needs to add property P3

 You deploy new class  A with P2 and P3 properties on a production system. Storage would be generated upon class definition and you will get the following:

All reads from P2 would deal with former P1 data.

All reads from P3 would read former P2 data (yes, you will get P3 initialized by former unexpected P2 data).

So you'll get some unexpected behavior and bugs with this.

Solution:

keep the storage definition within a class and in Git.

Maybe delete a property is a bad practice but sometimes we are doing that.

HTH

Thanks for the input on this. I have considered these negative consequences as you describe. I am pulling my data from REST services, so it would be perfectly fine for me to delete all my data if need be. Perhaps once the early phases of development are finished these diffs will become less active and not a problem.

The second reason is that I have been developing on both Caché 2017.2 and InterSystems IRIS. The storage definition changes slightly based on which one I am using, so it creates a little bit of noise, but it is ultimately manageable. Perhaps doing development across products is not recommended, so that could also be the answer

Wow. That's interesting. I'm curious what will happen if a class was created in Caché and then modified in IRIS (e.g. with new property) - would it be another global for a new property? Could you check that?

I think if you created class first in Caché 2017.2 and preserve the storage definition within a class in version control you should be good with IRIS - I mean IRIS shouldn't change the storage of your 2017.2 class.