Peeking at data in other schemas

Forums for specific tips, techniques and example code
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Peeking at data in other schemas

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:36 pm

by CarlRanson >> Tue, 19 Feb 2002 1:08:52 GMT

Hi all,

Just wanted to ask if this is easily possible before embarking on a wild goose chase.

I want to be able to have my prog lookup some data in another schema, which is a peer to the one my app is in.
eg.

RootSchema
Schema1
Schema2

I want to have an app in schema2 be able to read some data in schema1.

Is this possible? how?
Cheers,
CR

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Peeking at data in other schemas

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:36 pm

by dcooper@jade.co.nz >> Tue, 19 Feb 2002 3:10:49 GMT

Hi Carl,

Yes, this is possible (a facility called global instance visibility was added in JADE 5.0), but not in a particularly type-safe manner right now (you have to use indirect methods to access features of classes not visible in the schema branch of your process). It's also subject to a few restrictions.

The JadeScript below when run from Schema1 will get the first instance of a Schema2 Company class, write its name and also write the oid of the Joe Bloggs customer from the Company's dictionary of customers:

vars
scm : Schema;
cls : Class;
mkd : MemberKeyDictionary;
obj : Object;
begin

scm := rootSchema.getSchema("Schema2");
cls := scm.getClass("Company");
obj := cls.firstInstance;
write obj.getPropertyValue("name").String;
mkd := obj.getPropertyValue("allCustomers").MemberKeyDictionary;
write mkd["Joe Bloggs"];
end;

Prior to JADE 5, the above method would have got 1003 and/or 1046 exceptions.

As you can see, you can only work with common superschema types (I've assumed both Schema1 and Schema2 are directly below RootSchema as in your example) and you need to use indirect methods to get at things (eg: getPropertyValue, sendMsg, etc) which aren't type-safe at compile time, but they will certainly produce some nice exceptions at runtime if you get things wrong :-)

There aren't any restrictions on accessing properties, but the only methods a Schema1 process can invoke on an instance of a Schema2 class are *root class* methods (a root class is the top-most definition of a class). This means that subschema copy methods cannot be invoked (remember that any methods on Object, Application, Global, etc in your schemas are always subschema copy methods as the top-most definition of such classes is in the RootSchema), nor can primitive methods be invoked (again, primitive methods defined in user schemas are always on subschema copy types). If you are invoking methods across schemas remember that any code compiled in Schema2 that accesses app, global or currentSession will have been compiled against the Schema2 classes, but when executed from a Schema1 process, the app, global and currentSession objects are instances of the Schema1 classes, so properties/methods may not be available at runtime (this is a common gotcha when people start doing this kind of thing).

Work is underway on features for JADE 6 to make these "peer schemas" and cross-schema reuse/visibility easy and type-safe.

Dean.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Peeking at data in other schemas

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:36 pm

by CarlRanson >> Tue, 19 Feb 2002 3:38:12 GMT

That'll do nicely for now, as I only need to access limited amounts of data at this stage.

There are a couple of other ways that have since occured to me:

1. Using notifications to do a query/response mechanisim between an app running in each schema.

Im only guessing that it would be possible though, you'd have to have an app running for each schema, and use notifications on system or possibly node. Plus you'd be limited to passing primitive values I suspect.

2. Using odbc to export the class from one schema and import it into another.
Is there any reason you couldn't connect one jade db to another in this manner?

3. TCPIP connections.
Bit of a hassle, you'd need to come up with some sort of message passing protocol.

Anyone else tried any of these methods?
Cheers,
CR

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Peeking at data in other schemas

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:36 pm

by dcooper@jade.co.nz >> Tue, 19 Feb 2002 5:36:32 GMT
1. Using notifications to do a query/response mechanisim between an app running in each schema.

Im only guessing that it would be possible though, you'd have to have
an app running for each schema, and use notifications on system or possibly node. Plus you'd be limited to passing primitive values I suspect.

I'm aware of this being done several times. The Performance Testing Framework we have here uses exactly this mechanism to enable test driver apps to communicate with the test controller app (the controller and the drivers also run out of unrelated schemas). In many (most?) cases, queries and responses are sent as strings, but you're not limited to primitives. If all of the apps involved are in the same node, you can use shared transients - but if the apps are running out of unrelated schemas then you'll need to use getPropertyValue to access state. If the apps are running in different nodes then you can do the same thing with persistent objects, but if the notifications are frequent then the overhead of committing a transaction every time you want to send a query/response may be too heavyweight.
2. Using odbc to export the class from one schema and import it into another.
Is there any reason you couldn't connect one jade db to another
in this manner?

This is similar to the idea of exposing some objects as ActiveX components from one JADE environment and then importing them into another. Out of the box I suspect this won't work right now, as a single thread cannot connect to more than one database at the same time. If the ActiveX/ODBC driver is activated in-process, this will be a problem. You can do it, but will need an external process that manages the communication between two threads, each of which signs on to its own db (either directly, or via ActiveX/ODBC). We've had prototypes internally enabling a thread to connect to multiple databases, but that's as far as it's gone.

Dean.


Return to “Tips and Techniques”

Who is online

Users browsing this forum: No registered users and 11 guests