Generically handling MKD with unknown number of keys

[Patwos]

Has anyone written code to generically handle the collection returned by Table::getCollection or ComboBox::getCollection with respect to using an Iterator to do a startKeyGEQ on the collection when you don't know how many keys are defined for that collection?

For example, is there a way to tell how many keys, and what types, the MKD has?

I've tried using mkd.class.CollClass.getKeys but there is not much on the Key class that is available to identify the type, and I'm not sure doing a Key::getName and then looking for the details in brackets is the best approach for determining the type of the key!

Pat.

[Dennis]

I would try something along the lines below:

Code: Select all

vars k: Key; cls: Class; cc: CollClass; begin cc := MyCollClass; cls := cc.getMemberType().Class; foreach k in cc.getKeys() do write k.keyName() & " " & cls.getProperty(k.keyName()).type.name; endforeach;

Hope this helps.

[torrie]

I inspected the keys returned on one of my collections and they show up as MemberKey (Subclass of Key by the looks of it.) Typecasting the key returned as a MemberKey an additional method showed up (shown in Ctrl+Shift + 2) "getRootType" which appears to return the key type. This may be more robust if you have keys of the type myReference.property.

Note, the Key class and the MemberKey and ExternalKey classes don't appear in the help or when you browse RootSchema so they may not be officially supported.

[Patwos]

Thanks for the suggestions guys.

Torrie: Good call on the classes not being visible etc. I guess for now I only need to handle about 4 different collection class types, so I'll just go with a grubby "isKindOf" hack to know how many keys I need to pass to the startKeyGEQ call instead. Whilst that code is not particularly generic, at least I'm not using undocumented and therefore "subject to change without notice" classes etc.

Actually, it would be nice if the startKeyGEQ etc methods could just "assume null" for any keys that you don't provide as that is effectively all I'm using for the 2nd and all subsequent parameters to startKeyGEQ anyway.

Pat.

[bdoolan]

Hi,
That sounds like a good idea for an NFS (for LINCsters a bit like DT; GROUP versus DT; FROM). I haven't tried it but, in the meantime, the following method on Dictionary might help

Code: Select all

newStartKeyGeq1(key1 : Any; iter : Iterator); vars numKeys : Integer; begin numKeys := self.class().CollClass.getKeys().size; if numKeys = 1 then self.startKeyGeq(key1, iter); elseif numKeys = 2 then self.startKeyGeq(key1, null, iter); elseif numKeys = 3 then self.startKeyGeq(key1, null, null, iter); elseif numKeys = 4 then // etc endif; end;

You'll get runtime type checking of the supplied keys. Compile time checking should be available if Jade implement the NFS.

Clearly this can be generalised to have the first n keys supplied. For example

Code: Select all

newStartKeyGeq2(key1 : Any; key2 : Any; iter : Iterator);

Cheers, Brendan

[Patwos]

That looks surprisingly like my method... before I removed usage of the undocumented classes and instead put in a "kludge" to use isKindOf... since I know that I'm only dealing with 2 kinds of MKDs on this occasion.... but at some point it would be nice to have documented, and therefore supported ways of achieving this generically.

Pat.