MVITYPERTN in 2010.1

[Dawn Wolthuis]

All of our I-descs have an attribute like MVITYPERTN =
"FIELDNAME^P.CLASSNAME" where we place the compiled code in this
P.CLASSNAME.mvi file so that we can move them from one account to
another, rather than use the MVI.1.mvi with an increment for each new
I-desc.

We just learned that MVITYPERTN is not in 2010.1. So how do we write
I-descriptors now so that we can code them in "Pick" as the source and
they are projected as needed?

Thanks for any clues on this one. 'm hopeful the changes will be a
piece of cake (they will, right?). An example of a simple I-desc
specification for one that calls an arbitrary subroutine would be
helpful. I put an example of our current code related to one below.
Thanks in advance. --dawn

Right now in a persistent class we have:

Property OrgName As %String(MVHEADING = "Org Name", MVITYPE =
"SUBR('getpartynameOV',OfferingId)", MVITYPERTN = "ORGNAME^O.POSTING",
MVJUSTIFICATION = "L", MVPROJECTED = 1, MVTYPE = "I", MVWIDTH = 40) [
Calculated, SqlComputeCode = {
Set {OrgName}=##class(O.Posting).calcOrgName({%%ID},{%RECORD})},
SqlComputed ];

ClassMethod calcOrgName(ItemID As %String, Item As %String) As
%Integer [ Language = cache ]
{
Set $mvv(16)=ItemID,$mvv(17)=Item Quit $$ORGNAME^O.POSTING
}

In the related mvi class we have

FUNCTION ORGNAME() ; RETURN SUBR('getpartynameOV',@RECORD<15>) ; END

--
Dawn M. Wolthuis

Take and give some delight today

[Ed Clark]

I think you can just take out the MVITYPERTN parameter and everything
will continue to work. In your example, cmql will continue to use the
SUBR subroutine call, and object access will continue to call the
entry point in the O.POSTING mvi routine via calcOrgName.

MVITYPERTN was removed because it isn't necessary anymore. Itypes are
compiled on the fly, and the code that goes into attribute 13 of the
itype (which used to be MVITYPERTN) is now a precompilation if the
itype basic expression, and isn't a method dispatch anymore (so no
embedded namespace reference there to worry about).

Starting in 2010.1, you can use the more mnemonic $MVID and $MVRECORD
instead of $MVV(16) and $MVV(17). But you don't need them at all: your
computation method can be rewritten in mvbasic and you can get rid of
the O.POSTING mvi routine:

ClassMethod calcOrgName(ItemID As %String, Item As %String) As

%Integer [ Language = mvbasic ] {
@ID=ItemID
@RECORD=Item
CALL getpartynameOV(RESULT,@RECORD<15>)
RETURN RESULT
}

You could probably simplify it further if the getpartynameOV
subroutine doesn't use @ID or @RECORD internally:

ClassMethod calcOrgName(Item As %String) As %Integer [ Language =
mvbasic ] {
CALL getpartynameOV(RESULT,Item<15>)
RETURN RESULT

> --
> You received this message because you are subscribed to the Google
> Groups "InterSystems: MV Community" group.
> To post to this group, send email to Cac...@googlegroups.com
> To unsubscribe from this group, send email to CacheMV-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/CacheMV?hl=en

[Dawn Wolthuis]

Groovy! Thanks Ed, and the rest of the Cache' MV development team. You rock!
--dawn