RDK (OpenInsight Specific)
At 15 MAR 1998 12:52:07AM Don Bakke wrote:
Okay, I got my first full deployment made, but this has raised other issues and questions. I'm hoping these will help the RDK designer to trace down some of the loose ends:
1. I used the Publishable Entities dialog to make sure everything was just the way I wanted it to be. For some reason, some of my tables appeared in the Non-Publishable Entities list. I would move them all to the Publishable Entities side and click on Apply and all seemed to go okay. However, if I change Entity Type and go back to OpenInsight Table, those same tables are back on the Non-Publishable Entities side. Nothing I do will keep them where they need to be. What is really interesting is that some of the Non-Publishable tables were index tables but the data and dictionary files were on the Publishable Entities side.
2. Some indexes, however, did get deployed but the application never saw (or attached) them.
3. Is "DATA" the only subdirectory that a Full Install will deploy tables into? Can this be modified in advance? What happens if there are multiple data volumes, do they get merged into one?
4. Is there any way to know which SYSPROG entities can be set to non-publishable and still have a fully functioning runtime application? Or is every unnecessary entity already flagged that way?
That's all for now but I'm sure I've overlooked some. Thanks.
At 15 MAR 1998 09:54AM Aaron Kaplan wrote:
1. I used the Publishable Entities dialog to make sure everything was just the way I wanted it to be. For some reason, some of my tables appeared in the Non-Publishable Entities list. I would move them all to the Publishable Entities side and click on Apply and all seemed to go okay. However, if I change Entity Type and go back to OpenInsight Table, those same tables are back on the Non-Publishable Entities side. Nothing I do will keep them where they need to be. What is really interesting is that some of the Non-Publishable tables were index tables but the data and dictionary files were on the Publishable Entities side.
Yup. Reported as a bug. Hopefully it will be in 3.6
2. Some indexes, however, did get deployed but the application never saw (or attached) them.
Did not notice this, but it's probably related to the first problem.
3. Is "DATA" the only subdirectory that a Full Install will deploy tables into? Can this be modified in advance? What happens if there are multiple data volumes, do they get merged into one?
They should get merged into one, since the default is a copy table. In my deploys, I changed the %PROCESS% references to move items to the directory of my choosing and attached or copied them as needed. It's a bit of a pain and I talked to Cam about this in length a week or so ago.
4. Is there any way to know which SYSPROG entities can be set to non-publishable and still have a fully functioning runtime application? Or is every unnecessary entity already flagged that way?
No idea. You might be able to remove the VIM, MAPI and Notes stuff if you're not using them, but so much of it really depends on the app. There's the stuff for the workspaces and other development only routines that you could consider removing. If you're not using the reporter then you can remove the RW stuff and if you're not using FROM.TO BTREE.EXTRACT logic then you can remove those codes, but it's hard to really say which is which.
At 15 MAR 1998 07:20PM Don Bakke wrote:
Aaron,
Thanks a lot for your responses. They have helped, at the very least, give me the knowledge that I am experiencing normal problems with the RDK and it's not something I'm doing wrong.
They should get merged into one, since the default is a copy table. In my deploys, I changed the %PROCESS% references to move items to the directory of my choosing and attached or copied them as needed. It's a bit of a pain and I talked to Cam about this in length a week or so ago.
But isn't the %PROCESS% reference only valid when doing an Update deployment? What about full installation deployments? Should I just assume that after a full installation deployment I will need to move the data to where I really want it and then update the database definition?
If so, then it wouldn't it be easier just to tell the RDK not to deploy any datatables and simply copy them myself from my development directory to my deployment directory. BTW, this resolves another problem I have where the deployed tables use different DOS file names than the ones created by the development system.
At 16 MAR 1998 08:47AM Cameron Revelation wrote:
Don,
2. Some indexes, however, did get deployed but the application never saw (or attached) them.
There is a bug with index deployment that we are working on for 3.6. It is described in depth on the OI Works discussion.
Cameron Purdy
At 16 MAR 1998 10:38AM Aaron Kaplan wrote:
Yes, the %PROCESS% is only valid for updates. In the app I was refering to, the information that gets places in DATA is fine to stay there, since it's a separate location anyway.
If it were me, I'd deploy letting it put the data where it may, swap out engines, load up the deployment, copy things to where you want, then regen the DBT table.
The advantage of letting the RDK do it is that it creates the empty data tables for you. Otherwise, you have to clear them. Not that it's much work, but once I have working deployments, I can fire it off and leave the room.