go to post Herman Slagman · Mar 11, 2016 Did you know that when you define a ClassQuery that secretly behind the scenes a ClassMethod is being generated that executes the query ?For instance if you have a query Query ByName(Name As %String) As %SQLQuery(CONTAINID = 1){SELECT %ID,Address,City,Name FROM ClassQuery WHERE (Name %STARTSWITH :Name)}There will be a ClassMethod ByNameFunc(Name) which returns a %SQL.StatementResult object.
go to post Herman Slagman · Mar 11, 2016 Even simpeler: it could be an option of the mapping settings. Then there is no need for this pseudo-namespace.
go to post Herman Slagman · Mar 10, 2016 John, I've just did that and indeed that did the trick.I had the initial version, which probably didn't had the version info and update facility.
go to post Herman Slagman · Mar 10, 2016 I don't know if the image shows up, but there is no version info to be seen.
go to post Herman Slagman · Mar 10, 2016 It would be handy if we would see and be able to check some version or build number.If I look at the installed plugins, the all seem the have some sort of timestamp: 20151118, which doesn't look very up-to-date to me. Using the suggested link by Dmitry doesn't work for me: No Updates Found
go to post Herman Slagman · Mar 9, 2016 I didn't like to mess with your Gravatar question, so I raised a separate one concerning multiple emails/accounts: https://community.intersystems.com/post/using-another-email-address-account-community-wrc
go to post Herman Slagman · Mar 9, 2016 As I understood, the Atelier separate download was 'initial', you need to use the update features of Atelier (Eclipse) to get the latest client version.But i agree that upgrading Cache/Ensemble FT 2016.2 should include the Atelier latest version
go to post Herman Slagman · Mar 8, 2016 I assume your interfaces are all part of a bigger application, AFAIK there is no way to span an Ensemble Production across namespaces and from a EIA/ESB point-of-view having separate (connected) productions running on a single Ensemble instance doesn't make much sense.Your idea to have individual builds and deployments makes sense though, but that would be more stuff that a dedicated build/deployment tool should be able to do
go to post Herman Slagman · Mar 5, 2016 Bit that's exactly what I want: a smart code editor. Lean and mean. The Workflow bit I want to be handled by dedicated workflow (build, CI, CD) tools. I'm afraid that Atelier becomes Eclipse (sic): bloatware that tries to be a Swiss Army knive, but isn't succesful in any of it's features.
go to post Herman Slagman · Mar 5, 2016 There's where I find it a pity ISC choose Eclipse as a base for Atelier (love the name btw). Besides that I'm not a fan of Eclipse, I find it bloated and non-intuitive, the fact that plugins/extensions need to be written in Java limits (at least for me) the possibilities. A Javascript based IDE (such as Atom or Brackets) would make it much more accesible. That said, if ISC would be able to divise a plugin structure that is COS/Server based (at least partially) that might open up a lot of opportunities for seasoned COS developers.
go to post Herman Slagman · Mar 5, 2016 Considering myself among the 'the older and more established users of InterSystems technologies' ;-) we've always used the setup where each developer has his/hers own development machine. How the 'sandbox' namespace is called is not relevant. We use Git to tie the stuff together (more and more automated). It is allowed, or even encouraged, to use different versions of Caché or (in our case) Ensemble, which sometimes results in code that is not compatible with the current Production version, but we detect that in our QA phase and that might trigger discussions wether to upgrade Production if a used incompatible feature is of great value.Having a separate development sandbox leaves room for experimenting which you wouldn't have if every developer is working in the same namespace, where in my opninion 'not to step on each others toes' would be much too constraining.It will probable the same when Atelier takes off, some of us will be using that while others will stick to Studio or even brew their own in MS Code.
go to post Herman Slagman · Mar 4, 2016 That's the point you make the decision based on values of elements or attributes within those elements, XSLTs XPath expressions make it very easy to address and 'extract' those.
go to post Herman Slagman · Mar 4, 2016 XSLT in combination with %XML.XSLT.CallbackHandler is an excellent way to extract information from a (large) XML file.We use it to perform XML Shredding and flattening on very large XML.
go to post Herman Slagman · Mar 4, 2016 If you're controling the webservice 'on the other side', the best way to handle this is to make it asynchronous, just returning a sort of Ack that the message is received.Depending if you need information back or not the service can return a status back.Also since the service seems to provide rather unrelated functionality, it might be a good idea to split the service up in different services.
go to post Herman Slagman · Mar 3, 2016 The same security precautions would be for generator methods which can execute any code as well during compilation.
go to post Herman Slagman · Jan 26, 2016 Does this mean there won't be a 2016.1 ? If not what is the expected release period of 2016.2 ? The name suggests Q3 2016 ?
go to post Herman Slagman · Dec 19, 2015 Glad to have these kind of discussions. I didn't mean 'huge overkill' in the sense of amount of bytes, but merely the stack that is needed to run a simple Cache service (Docker, Linux and a complete Cache instance). And yes, it's a huge improvement compared to VM's. Now (at least in this phase of containerization) you need to know quite some Linux and since I'm not a DevOps guy, I don't want to know Linux (or any other OS for that matter) beyond being able to use it. I've been working on a skunk project (Bento) that tries to provide containerization just using Cache. My thoughts are about two kinds of containers, application (code) and data containers that expose a REST interface. Applications don't have a state so they can be instantiated, upgraded, replicated quite easily. The problem is with the data containers, they can be instantiated from a initial state ofcourse, but the amount of catching up to do in terms of data synchronization could be substantial. It depends on the granularity of the data, but it makes no sense to instantiate a data container that needs to catch up terrabytes of data. Bento is far from being published, not even as a demonstration, but I might put together a little presentation that explains its principles. I don't think we need/want/can rebuild all the stuff that Linux provides, but it should be possible to sandbox a namespace a lot more then is prossible right now. I think both solutions (Cache in a container and Cache as a container) can both exist, each having it's own advantages.
go to post Herman Slagman · Dec 17, 2015 Bill, Luca, Have you ever considered Caché as a container as opposed to in a container ? Secure (sandboxed) small applications (let's call them MicroServices ;-)) easily deployable, replicable and synchronizable across multiple Caché instances. I still find Docker containers a huge overkill (in terms of needed stack) if all you want to containerize are Caché applications.
