AllAccepted answers
Evgeny Shvarov · Jun 3, 2019

Stores data on disk? Meaning, that if we create these persistent classes, the data is stored twice? Once in the global node and in some other format as defined (or not defined by the class)?  

ANY data in Caché and IRIS is stored in global and it's not stored twice, everytime in a global, which is in the storage strategy of the persistent class.

Any SQL table in Caché and IRIS has the related persistent class in the metadata.

But just to reiterate, how does the DDL interpret a read definition into a write definition? The data stored in the global node and the definition do line up exactly (in our case, almost not at all).

Could you elaborate, please?

Just in case: you can deal with Caché and IRIS as with any relational DB: use DDL, SQL via ODBC/JDBC.

And yes, every time you call

CREATE TABLE A 

the new persistent class A is being created on the backend to store data in ^AD global.

Evgeny Shvarov · Jun 3, 2019

It's all about multi-model nature of IRIS and Caché.

Everything in Caché and InterSystems IRIS is being stored in globals - key-value sparse stored arrays.

Every persistent class (a class which stores data on disk) has the map of how the data should be stored in a particular global (globals).

ObjectScript Class definition provides the API of how the data will be stored and read from a global (globals) via Object Script or SQL access.

You can specify standard or custom storage strategy for a class. 

The persistent 'SomeClass' class with standard storage strategy will provide the API to store data in ^SomeClassD data for data itself and ^SomeClassI global for indexes.

You can see the storage strategy of a class in the source code of a persistent class immediately after successful compilation - it will be visible in a related XML block at the bottom of the class.

In your case you have a custom storage strategy which could be everything. Check @brendan.bannon's series on that which could be really helpful for you.

As @Eduard Lebedyuk mentioned, if you delete the class as source code (e.g. via Management Portal)  it will not delete the data itself.

But! As @Robert Cemper mentioned if you delete it via SQL API with DROP statement it will delete data in a global too (because we suppose the data to be deleted if we DROP a table, right?).

HTH

Evgeny Shvarov · May 17, 2019

Hi!

You can request for a fully licensed IRIS on this page

If you want to try or use IRIS features with IRIS Community Edition:

Try IRIS online

Use IRIS Community from DockerHub on your laptop as is, or with different samples from Open Exchange. Check how to use IRIS Docker image on InterSystems Developers video channel.

or run Community on Express IRIS images on AWS, GCP or Azure.

HTH

Evgeny Shvarov · May 6, 2019

Hi @Anton Umnikov ! Thanks for raising this topic. 

The question of the most acceptable folder structure widely discussed already on community. 

As for Atelier, - why do you care where it puts the code? I believe you can maintain your code in a folder structure you like and let Atelier compile it and bring back in a place it took it, right?

Evgeny Shvarov · May 2, 2019

Guys, thanks for a lot of options! It looks like it is a relevant question ;)

Personally I feel that 3 parameters for a method are OK, but 4 is too much. But how much is for an average developer? Is there is a consensus about it?

If I know, that method will accept a lot of settings and not all of them are mandatory, I like the .args approach, which @Robert.Cemper mentioned and which, e.g. is introduced in e.g. in Database, Namespace and Web App management functions. E.g.:

set props("NameSpace")="Namespace"

set props("Enabled")=1

set props("DeepSeeEnabled")=1

Do ##class(Security.Applications).Create("AppName", .props)

It's readable and you don't count commas.

Also I'm curious if we can setup and pass a JSON that easily too? Would be great.