Tuesday, May 7, 2013

ER diagram from an existing ORACLE DB

In SQL Developer 3, this is very straight forward;

View > Data Modeler > Browser.

The browser will show up as one of the tabs along the left-hand side.
Click on the Browser tab, expand the design, right-click Relational Models and select 'New Relational Model'.
Then just drag the tables you want onto the model.

To save/export the diagram to a PDF do;

File > Data Modeler > Print Diagram > PDF

Follow instructions to finish

happy modelling

Friday, May 3, 2013

TRUE/REAL data pagination


I was recently implementing Lazy Loading in Primefaces

One of the insights i would like to share is that real efficient pagination is achieved by fetching data from the database (backend) in chunks as opposed to loading everything in memory.

This saves both bandwidth and memory (client side).

The trick here is to use OFFSET and LIMIT sql clauses in conjuction with ORDER BY.

Example 1: Returning the first 100 rows from a table called employee:

SELECT employee_id, employee_name, remarks FROM employee ORDER BY employee_id ASC LIMIT 100;

Example 2: Returning 10 rows from the table employee starting at row 15

SELECT employee_id, employee_name, remarks FROM employee ORDER BY employee_id ASC OFFSET 15 LIMIT 10;



Monday, April 29, 2013

LMFAO - Looking Manualy for Abnormal Output


Dont use System.out() for debugging a serious java app. Use logs(runtime) and JUnit for testing.

The best explanation is (from a StackOverflow thread)

Question(part):
"Whether I write simple applications or larger ones I test them with the System.out statements and it seams quite easy to me. " and on he goes asking whay he should use JUnit.

Answer(part):

That's not testing, that's "looking manually at output" (known in the biz as LMAO). More formally it's known as "looking manually for abnormal output" (LMFAO).
Any time you change code, you must run the app and LMFAO for all code affected by those changes. Even in small projects, this is problematic and error-prone.
Now scale up to 50k, 250k, 1m LOC or more, and LMFAO any time you make a code change. Not only is it unpleasant, it's impossible: you've scaled up the combinations of inputs, outputs, flags, conditions, and it's difficult to exercise all possible branches.
Worse, LMFAO might mean visiting pages upon pages of web app, running reports, poring over millions of log lines across dozens of files and machines, reading generated and delivered emails, checking text messages, checking the path of a robot, filling a bottle of soda, aggregating data from a hundred web services, checking the audit trail of a financial transaction... you get the idea. "Output" doesn't mean a few lines of text, "output" means aggregate system behavior.

Lastly, unit and behavior tests define system behavior. Tests can be run by a continuous integration server and checked for correctness. Sure, so can System.outs, but the CI server isn't going to know if one of them is wrong–and if it does, they're unit tests, and you might as well use a framework.
No matter how good we think we are, humans aren't good unit test frameworks or CI servers.


Source StackOverflow

Friday, April 19, 2013

Conditional Triggers in Postgres


Since version 9.0 we can execute triggers conditionaly

Example

CREATE TRIGGER trGenerateSchedule
AFTER INSERT OR UPDATE OF is_confirmed ON job_location
    FOR EACH ROW
    WHEN (NEW.is_confirmed = true)
    EXECUTE PROCEDURE generateSchedule();

This is a column trigger that listens for a change (to true) of a single column in the job_location table