ORACLENERD

OBIEE and Source Control?

One very difficult aspect of using OBIEE (or APEX for that matter) is that it doesn't lend itself very well to source control.

There is one RPD (metadata) file in use at any given time. Changes to this environment will affect anyone using or developing on the presentation server layer (Dashboards/Answers/etc).

For the web catalog (Answers/Dashboards/Prompts/etc) you can make changes, but again, it will affect anyone who is also using the tool. If you want to tweak a report that has prompts or filters, you need to save everything off to your own folder in order to work on it or risk colliding with others or worse, messing up the report beyond repair (also known as FUBAR).

Developers usually need to break things to fix them and giving them an environment where they can do this (also known as tinkering), without repercussions, should be high on the list of must-haves.

Inspired by a meeting I attended last week and Jake's recent welcoming of VirtualBox into the Oracle fold, I decided to think (yikes) my way through a possible solution.

After the meeting last week, I was convinced I could build an environment using subversion as the source control tool. Tie that in with Jira, Fisheye and ultimately Bamboo and you'd have a pretty sweet environment to work in. How to do it though?

1. Set up source control. SVN is free and runs on Linux. Free.
2. Convince a multitude of developers to install and configure OBIEE on their own workstations. Yeah...not so sure about that. I accidentally said in that meeting, "I don't know a single, good developer who doesn't have a local install of Oracle (the database)" May have been just a tad hyperbolic...I like to tinker and appreciate those environments which allow me to do so. Having a local sandbox has been indispensable for me.
3. Not sure where or what 3 is. That's where I got hung up...until reading Jake's post.

How about this then?

1. No subversion (for the time being).
2. Virtualize the development environment.
3. Hand out the VDIs to the developers, and let them run with it. When they make changes, they can promote them through the usual channels. Once those changes are accepted/merged with the development environment, a new snapshot is taken and distributed.

Having the snapshot of dev is the key I think. Those who don't like to tinker, who just like to get their job done, won't have to worry about configuring their environment. They'll just fire up the VM and do their work. For those that do like to tinker, they can fiddle with the VM as much as they want without fear of breaking things for everyone else. If they need a fresh start, just get the original VDI and go crazy again.

This hasn't been completely thought at (if you couldn't tell). I haven't considered passwords or other such sensitive data. It sounds good in my head though. What's the worst that could happen?

Labels: design, obiee, source control

¶ 2/08/2010 11:43:00 PM 2 Comments Links to this post

Random Things: Volume #13

A brief respite for me...I get to work remotely this week.

Admittedly I have gotten into the habit, finally, of traveling, so it's a little strange to be home (never thought I would say that). There is no shortage of respect from me for those who travel all the time. It's a hard life.

OBIEE Performance
Our Usage Tracking reports are a tad slow and I've been looking into the logs trying to decipher them. Unlike the database which has a multitude of resources, OBIEE has hardly any. Christian did point me to this Mark Rittman article, which is good, but not great (not because the author is lacking...there just isn't that much to go on). rnm1978 suggested MOS, but I don't have access right now...besides, it seems to be having problems again anyway.

While I'm on the subject of performance and rnm1978, I should link up to this article which highlights 3 recent posts by Cary Millsap. All 3 are excellent reads and require your immediate attention.

Kate
The reason I am home this week is so that I can go to a Doctor's visit with Kate. We finally found a place where they might be able to help diagnose her. Most of her doctors have been more concerned with keeping her alive (healthy) and haven't worried too much about her developmental delays (still not talking...but she can sign "daddy"). Anyway, the place is called The Tridas Center and we're excited/nervous. Excited about finding her better help and nervous about the possibilities (more specifically, what a diagnosis would mean).

Labels: kate, obiee, random

¶ 2/08/2010 03:49:00 PM 2 Comments Links to this post

PRIMARY KEY and NOT NULL

I've seen this far too often. A table with a primary key (good) and a check constraint (NOT NULL) on the same column.

Stop doing it. Watch.

CREATE TABLE t
(
  id NUMBER
    CONSTRAINT pk_id PRIMARY KEY
);

SH@I_HAVE_NO_IDEA>INSERT INTO t ( id ) VALUES ( 1 );

1 row created.

Elapsed: 00:00:00.33
SH@I_HAVE_NO_IDEA>INSERT INTO t ( id ) VALUES ( NULL );
INSERT INTO t ( id ) VALUES ( NULL )
                              *
ERROR at line 1:
ORA-01400: cannot insert NULL into ("SH"."T"."ID")

As HillbillyToad said,

It is better than no constraint, that's for sure. The heart was in the right place...

Labels: constraints, development, sql, wtf

¶ 2/03/2010 07:46:00 PM 13 Comments Links to this post

TNS-12533: TNS:illegal ADDRESS parameters

I kept receiving this error recently but until today, never bothered to investigate it. To get around it, I would just comment out the bottom half (where the problem was) of the tnsnames file.

Today I had enough.

I removed all but the top most entry, saved the file and did a tnsping <first_entry>.

OK (40 msec)

I added in the second entry, tnsping <second_entry>

OK (210 msec)

I added in the third entry

TNS-12533: TNS:illegal ADDRESS parameters

Removed it.

Success.

WTF?

 TESTING = 
  (DESCRIPTION = 
    (ADDRESS = 
      (PROTOCOL = TCP)
      (HOST = localhost)
      (PORT = 1521)
    )
    (CONNECT_DATA = 
      (SERVICE_NAME = TESTING)
    )
  )

It's probably difficult to see...maybe a picture would do better.

see it?