November 26, 2004
Validating Relax NG with libxml2 and Python
def fileRead(filename, attrib):
myFile = open(filename, attrib)
contents = myFile.read()
def isValid(schemaFileName, instanceFileName):
success = False
schema = fileRead(schemaFileName, 'r')
instance = fileRead(instanceFilename, 'r')
rngParser = libxml2.relaxNGNewMemParserCtxt(schema, len(schema))
rngSchema = rngParser.relaxNGParse()
ctxt = rngSchema.relaxNGNewValidCtxt()
doc = libxml2.parseDoc(instance)
ret = doc.relaxNGValidateDoc(ctxt)
if ret == 0:
success = True
# Validation completed, let's clean up
del rngParser, rngSchema, ctxt
if libxml2.debugMemory(1) != 0:
print "Memory leaked %d bytes" % libxml2.debugMemory(1)
As usual, I'm liberally borrowing from the work of others. I defined my schema file after a quick skim through the Relax NG tutorial. The libxml2 documentation was worse than useless but google bought AMK and Dave Kuhlman to my aid.
There is a remarkable similarity between their code and mine, the working parts are theirs and the bugs are all mine. I'm posting my snippet because it is the simplest possible way I could find to validate my XML document against my schema and that's quite useful to me.
November 25, 2004
Thinking of developing your application to be database independent? Don't. The long answer is in this post on Mark Rittman's blog the short answer is in a quote from it;
"Database-independent code doesn't use features, it uses vanilla-flavored, lowest common denominator elements - so you pay every penalty, but never pick up the benefits."
It's another fine piece of writing from the always excellent Mark. I'm referencing it here as an aide memoire for the next time a wet behind the ears Java programmer tells me that the database is just somewhere to persist object instances.
November 24, 2004
Better Late Than Never
Just as traction is growing for more feature rich and complete version control systems , Oracle has added support for CVS to JDeveloper. How hard would it have been to include support for subversion as well?
[Courtesy of Steve Muench]
November 16, 2004
Small Patch to pwyky
Inspired by Stuart Langridge I took a look at pwyky today. I've been wanting to put a wiki on this site for a while, it's just been languishing near the bottom of my todo list. This looked just the thing for me though, and at under 30k of code in a single file I thought it would be possible to install and configure it in my lunch hour.
Sure enough, in about ten minutes I had downloaded the script and got it running on my iBook. Before I put it up on my public web site I wanted to make a minor tweak, and that was to get it looking the same as my other pages. Whilst I could have edited the supplied stylesheet I wanted to keep my site simple. Ideally I wanted to reference my existing site wide stylesheet in pwyky. I could have just hacked the script to reference it but looking at the code it didn't seem too hard to do a proper job and make the stylesheet a configuration parameter. The code is nicely written and easy to tweak so adding it was a breeze.
After a little bit of tinkering my work was done and you can see it in operation here. Because pwyky is GPL code, and in the spirit of the commons, I thought I should make my patch available. For those that are interested I've posted it to my code directory. Just download pwyky.py.txt and follow the normal installation instructions which can be found on the pwyky home page.
The only difference from the standard version is the addition of an extra parameter stylesheet. It should point to the stylesheet relative to the document root of your web server. So, for instance, my wiki is in /wiki but my stylesheet is in /styles. All I did was add an extra line to my config.txt file which looks like this;
As with the other configuration parameters for pwyky, if you don't specify it in your configuration file then the default is used.
November 10, 2004
Deploying Mappings in Oracle Warehouse Builder
I just fell into a trap for young players, and spent a good couple of hours this morning trying and failing to deploy a mapping from Oracle Warehouse Builder to my development environment.
As an aide memoire and general help for anyone else in the situation here is what you need to do to deploy a mapping. For those new to Warehouse Builder beware that it has quite a complex internal model of the world. This allows it to support all kinds of different implementation models and configuration management scenarios. It can cause quite a bit of confusion to the simple minded developer trying a simple deployment to their own database though.
For the purposes of this discussion I am running Warehouse Builder version 18.104.22.168.8 although you should see the same behaviour with 10g (version 1).
I assume that you have successfully built and validated your mapping in the mapping editor. As part of this you will have needed to define at least one source module and a target module. You then need to define a location for each of these modules. The modules are roughly equivalent to database schemas (or collections of objects) and the locations are roughly equivalent to database instances (or a collection of data files and associated processes).
The final piece of the jigsaw is a runtime repository. This needs to be created and initialised using the Oracle Universal Installer on the same machine that your database runs on. Once that is installed you need to tell your Warehouse Builder client (and design repository) about it. Right click on the Runtime Repository Connections item in your project tree and select "Create Runtime Repository Connection", or press control-n.
With all of this done (and committed to the design repository) start the deployment manager. You can start it from the Project menu in the Warehouse Builder client or by double clicking on the Runtime Repository Connection you have created, or by right clicking on the Runtime Repository Connection and selecting "Editor ..." or by typing control-o.
Next, and this is where I failed spectacularly, you need to register all of your locations with the runtime repository. I think that this is a superfluous step and should really be done for you by Warehouse Builder. Once I try and deploy a mapping, or any other OWB component, the runtime repository should be updated with all of the details necessary for it to work. But this isn't the case so you have to do it manually before attempting anything else. Right click each of your locations (which the Warehouse Builder will have picked up from the design information you entered) and select the "Register" option.
Once this has been done select the object you wish to deploy, give it a suitable deployment action, pause whilst you look for the commit button or menu item that isn't there, press the deploy button (and look confused when a commit dialogue appears) and Bob should indeed by your Mother's brother.
Once more, I couldn't help think that a bit of task based product documentation would have been useful here. The Oracle by Example lessons helped and are definitely a step in the right direction, but still more should be done in the standard documentation that ships with the product. Bad Oracle.
You can probably tell from some of the preceding paragraphs that I'm quite amazed at how bad the user interface to OWB is. I need to spend some more time with the tool before I can do it justice though so I'll probably post a seperate entry on it.
November 05, 2004
Installing Oracle Warehouse Builder
I've recently had quite a few goes at installing Oracle Warehouse Builder 10.1, each of which has been a glorious failure. Today I found the cause of my pain and, delight of delights, a solution.
I was failing to install the repository into my development database. For those new to the world of Warehouse Builder the tool stores the design information you supply in a series of tables (with associated sequences, triggers, views and code objects) called the repository. Before you can define mappings and transformations you need to create this repository.
My problem lies, I think, in the fact that I was trying to create my repository in an Oracle 9.2 (as opposed to 10g) database with a unicode character set (in my case 'AL32UTF8'). This combination causes the repository assistant to crash when populating the repository tables with seed data. The error I received was;
INS0017: Installation of seeded data failed
INS0029: Error occurred during installation. Check the log file C:\Oracle\product\10.1.0\OWB\owb\reposasst\log.txt for details
Checking the log file wasn't much use as it just showed an enormous exception stack from when the error occurred with the primary culprit being SetCurrentProjectExceptionSDK1001. Various searches on metalink hadn't revealed much, until I used the exception itself as my search string
Then I found this forum thread which mirrored my experiences and provided a solution. For those without access to Oracle support the problem (and solution) lies in the use of the thick Java JDBC driver in this particular circumstance. Telling OWB to use the thin JDBC driver for the duration of the repository installation solves the problem and allows the repository creation to work. The steps, as detailed in the forum thread, are;
1) Locate OWBHome\owb\bin\admin directory (Windows) or OWBHome/owb/bin/admin (Unix)
2) Create a file jdbcdriver.properties in this directory with the following line ONLY.
3) Create OWB Repository
4) After successful creation, delete the above created jdbcdriver.properties file