All
Accepted answers
Evgeny Shvarov · Jun 10, 2017 go to post

HI, Mike!

You don't have to. DC Telegram Channel is introduced for those who loves Telegram  mobile app as a way to communicate.

It is yet another channel to deliver DC content which is already posted on DC or DC YouTube.

But, we plan to introduce DC bot which can be interesting and unique for DC Telegram Channel.

Evgeny Shvarov · Jun 9, 2017 go to post

Thanks, Vitaly!

That looks exactly like what I want. I'll give it a try. Except with not very clear magic with SQLStorage. 

Is there any way to "generate" compatible storage? And why SQLStorage? Why not default CachéStorage, but copy-pasted from Class A?

Evgeny Shvarov · Jun 9, 2017 go to post

VIews work for SQL access. I really need a kind of view, but for classes paradigm: so I could have access to Class B property P2 with Caché object access.

Evgeny Shvarov · May 31, 2017 go to post

When I've seen "ORM javascript" in the feature list I remembered yet another very interesting approach which is in fact the result of Hachathon took place in  Moscow two years ago: CNDO (Caché Node Data Object), project made by [@Nikita Savchenko], Anton Gnibeda and [@Irene.Mikhaylova].

Evgeny Shvarov · May 26, 2017 go to post

Thanks, Dan!

That definitely makes sense.

What I like about object callbacks is the code readability. Compare:

Method %OnBeforeSave(insert as %Boolean) As %Status [ Private, ServerOnly = 1 ]

{

if insert s ..CreationDate=$H

q $$$OK }

And 

Property CreationDate As %TimeStamp [ SqlComputeCode = { set {*}=$zdt($h,3) }, SqlComputed, SqlComputeOnChange = %%INSERT ];

What if I would need to refer to other properties in

{*)=expression()

Or the expression would be complex and if I want to debug it?

Is there a way to keep callbacks readability and have the callback methods  be fired for object and SQL access both?

Something like:

Property CreationDate As %TimeStamp [ SqlComputeCode = { set {*}=..%OnBeforeSave(1) }, SqlComputed, SqlComputeOnChange = %%INSERT ];
Evgeny Shvarov · May 26, 2017 go to post

Thank you, Rubens, Fabian, Sean.

Agreed, that Initial expression is the best option here. And thanks for the explanations on the callbacks!

Evgeny Shvarov · May 26, 2017 go to post

Thanks, Sean!

JSON-RPC library

Would be great to look into this if you want to expose it some day.

Evgeny Shvarov · May 25, 2017 go to post

Hi, Vineeth!

See the sample of exporting and importing global to zip file on the fly from @Eduard Lebedyuk post:

set ^dbg=123
set s=##class(%Stream.FileBinaryGzip).%New()
do s.LinkToFile("1.xml")
do $System.OBJ.ExportToStream("dbg*.GBL", s)
do s.%Save()
kill
kill ^dbg
set s=##class(%Stream.FileBinaryGzip).%New()
do s.LinkToFile("1.xml")
do $System.OBJ.LoadStream(s)
write ^dbg
>123

Hope that helps.

Evgeny Shvarov · May 25, 2017 go to post

Yes, you are right and I agree. George, thank you very much for thorough explanations.

Evgeny Shvarov · May 25, 2017 go to post

So, it's never safe to go without storage schema (even with default storage schema) if you want to either to delete or add new class properties.

Evgeny Shvarov · May 24, 2017 go to post

So, in the end, if I want to store in VCS only class body (without storage schema)  it is safe to do it if:

I use only default storage schema in this project;

I never delete properties and use "deprecated" clause instead.

Right?

Evgeny Shvarov · May 24, 2017 go to post

Right. But I would never delete and change the name of the properties if you have the data behind them already. I prefer "deprecated" approach of "deleting" unused properties.

I think it is a good candidate for another question. 

Evgeny Shvarov · May 24, 2017 go to post

Yes, sure. If you customized the default storage (which is not very recommended, see @Kyle Baxter's answer) on purpose it becomes the part of the solution and should be stored in VCS along with class def. 

Evgeny Shvarov · May 24, 2017 go to post

If you have customised the storage schema

But how can I customize it? Do you mean manually?

When I export the class def to the file I have the regenerated schema every time. So the only way to customize it is to change the schema manually in exported file. And this would be the risk to experience problems after importing that class.

To be clear, I do keep schema with the class def in Git and I never ever changed (hope so) this part of the class definition. It is useful for me only for information purposes to know where  the data is stored.

 So here is my question: why should I export and keep this part of class def if I don't want to know where is the data and don't want to have risk to manually change the storage data?

This can have serious consequences as data may get stored in a different place from data stored by previous versions of the class.

I believe if you change properties and indexes of the persistent class it would definitely cause  serious consequences on the data of previous versions of the class (but happily here we have the recipe of data conversion and etc).