Friday, January 25, 2008

 

Stupid PL/SQL tricks

I needed to load a a few gigs of test data into an Oracle tablespace. Sadly there really aren't any tools for the task. I created a simple table with two columns: id (integer, which apparently is an alias for number(38)) and data (char(512)). PL/SQL code blocks are a little bit more formal than most SQL variants:
DECLARE
i NUMBER;
BEGIN
for i in 1..10000000 loop
insert into sys.t1 values(i,'ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ABCDEFGHI ');
end loop;
END;
Other notes: Every user has a schema. Users are granted permissions to create objects in tablespaces via quotas (although most god roles bypass quota checks). To see if archive logs are enabled, use ARCHIVE LOG LIST;.

Monday, January 21, 2008

 

OT: Rock band

Just a quick off-topic note: if you are serious about Guitar Hero or Rock Band, my friend Mike is running a blog about it. He has worked really hard on this blog and the content so check it out and add the feed to your reader if you want an easy way to keep up with the latest simulated rock-n-roll news (I am a very occasional contributer there as well):

http://www.rockgamer.com/

Labels:


 

The art of software development

A team in our company recently created a new API to integrate with a legacy system. The technology behind this new API? HTTP POST, no SOAP or anything fancy. This worked out real well for me since we don't use this legacy system except in the most cursory and peripheral way, so I only needed the barest of interface. In fact, we derived a lot of benefit just by creating a two field form (with the rest of the data in hidden fields) to this application.

I talked to the application's developer about the interface. I asked him (with as much diplomacy as possible) if HTTP POST was his first choice of interfaces. Personally I would have used SOAP for this one. POST is OK but for two issues - first, you can't give an array of values as parameters with POST. Instead, you have fields like TITLE1, ABSTRACT1, CATEGORY1, etc etc etc. Second, there is no meaningful, machine readable way to send data back to the caller. You wind up assuming that a person is going to be the ultimate consumer of whatever result or error message this API spits out. What he said to me has been spinning around in my mind for a while.
"The art of software development is the art of compromise."
What a true quote, thank you Ryan H.

I write this as I am neck deep in a side project involving a SOAP interface to an ORM managed database. I've been procrastinating on this project. I am avoiding writing the hibernate XML descriptors for the structure. I have the DB created in MSSQL from visio diagrams, but hand crafting all this XML from the structure of about 30 tables.... ugh. Hopefully I'll get to it in the next week or so but I've put it off for nearly a month so far.

Labels: , , , , ,


This page is powered by Blogger. Isn't yours?