Have a look at this blog entry from Dave Schleis:
That should answer your first question. And browse around Dave's blog - he has a few articles on scripting Data Modeler, some intended for people getting started with this powerful capability.
you can read SQLDeveloperDataModelerScripting.docx located in datamodeler\datamodeler\xmlmetadata\doc directory of your DM installation.
It's written there - model.getStorageDesign() will return the physical model for that relational model - it could be closed.
Each physical model is also RDBMSSite and there is RDBSSiteSet at design level - visible in "Tools>RDBS Site administration". So to get physical model for specific RDBMSSite (not the current one set to relational model) you need fist to get the site:
site = model.getDesign().getRDBMSSiteSet().getByName("site name as it's set");
//get storage design (physical model) now
sd = model.getStorageDesign(site);
to set the index you need to get presentation for that index in physical model
Thx a lot - again ;-) Actually I did find the documentation and tried to get along with it.
What I did not find was that site = model.getDesign().getRDBMSSiteSet().getByName("site name as it's set"); part.
And this is what did puzzle me cause you may have more then one phys model and I wondered how DM might by magic chose the "right" one.
So this most probably was the missing hint.
Anyway, my script is working now and I did learn a lot.
Kind regards and thanks a lot again, Hans
BTW: When you debug such a script the cursor position is off by some lines. So when you click a branch actually the one 2 or 3 lines above is opened.
I did take a look at Dave's blog.
But I struggled with Groovy and didn't get it working in time before Philip added his comment and saved Nashorn.
And actually while I find that Groovy approach pretty neat - for me the Nashorn approach using arrays and indexes is easier to understand.
And Nashorn can be debugged so you can step through your code and look up what methods may be called.
In my humble opinion that's much easier than consuming that XML Metadata documentation.
Kind regards, Hans
But thanks anyway for your response! It made me peek into Groovy.