Static Schema

I've written a method to read in a schema and generate a schema.cls file with the defintions. Have a look at this bit of code:

using proparseclient.*.
 
DEF VAR i AS INT NO-UNDO.
DEF VAR j AS INT NO-UNDO.
DEF VAR S AS INT NO-UNDO.

s = mtime.

do I = 1 TO 100000:
 assign j = Schema:JPNode_RecordSize .
end.

message "Loop Time (ms):" mtime - s SKIP

        "Node Record Size:" Schema:JPNode_RecordSize SKIP
        "Node Type OffSet:" Schema:JPNode_type_offset SKIP
        
        "BlockNode Record Size:" Schema:BlockNode_RecordSize SKIP
        "BlockNode File Index OffSet: " Schema:BlockNode_fileIndex_OffSet 
        
        view-as alert-box INFORMATION.

boy, it runs fast (the loop on my machine takes 54ms!) . It also makes the code look really readable, and we don't have to define variables all over the place. I think it suits everyone's requirements.

The class properties are defined as static, so we can reference them straight away. The code block above runs unaltered.

Comments ?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
john's picture

good

That's good. It wasn't an option with 10.1B, but since Jurjen has given his blessing for 10.1C, this is good.

So now there's no need to generate the schema.cls file at run time, is that right?


That's right. I've created a

That's right. I've created a class called MakeSchema.cls which will generate the new schema.cls file as and when we need to - This probably would only ever be used internally, and schema.cls shipped with the next version of proparse.


john's picture

schema.cls

One of the requirements which influenced the design of the blob was that the deployment of proparse.jar would be independent of any client code like Prolint and the API.

Sorry. Schema.cls really needs to initialize its variables sometime at startup or else when the first ParseUnit starts requesting offsets.


that's not a problem. Could

that's not a problem. Could we have a schema version ID as the first byte of the schema - then we could identify it the schema has changed, and rebuild schema.cls when we find a new revision.


john's picture

version ID

OK. I can't actually give you a schema version ID, but I can give you a proparse.jar build number, which should give you what you need.


that is more than good

that is more than good enough. Thanks.


using the static schema in

using the static schema in nodes does not really impact on performance (down to 2000ms from 2065ms) but the code does look a lot nicer :)

Initial load of the parseunit now goes down to <10ms because there is no need to load the schema