views:

46

answers:

2

Say you generate ddl to create all your db tables etc via Hibernate SchemaExport etc. What you get is a script which starts with drop statements at the beginning. Not a problem, as I want this. But running this script produces a crapload of ORA-00942 errors running on an Oracle db.

Since they're not really errors if the tables just didn't exist yet, I'd like my create script to be error free when it executes so it's easy to determine what (if any) failed.

What are my options? I DO want drop statements generated since tables may or may not exist yet, but I don't want a million ORA-s coming back at me that I have to check (to determine if they're actual errors) just because it couldn't drop a table that's brand new.

+1  A: 

If you get a script of drop statements, and Hibernate won't do it for you then wrap the DROP TABLE statements in an IF to test if the table exists before dropping it:

IF EXISTS(SELECT NULL 
            FROM TABLE_XYZ) THEN
  DROP TABLE TABLE_XYZ;
END IF;
OMG Ponies
Preferably Hib would do this for us, but assuming it can't I may try writing something to do this after ddl generation. Still, I was hoping for a slightly easier method. :( +1 for SOME solution at least
Crusader
@Crusader Create a Jira issue... and submit a patch :)
Pascal Thivent
Was thinking about it, but decided it's "probably" not worth the trouble given what I'm using it for.
Crusader
@OMG Ponies, please read: http://meta.stackoverflow.com/questions/66352/do-we-really-need-a-tag-for-every-error-code
NullUserException
+3  A: 

"Say you generate ddl to create all your db tables etc via Hibernate SchemaExport etc. What you get is a script which starts with drop statements at the beginning. Not a problem, as I want this. But running this script produces a crapload of ORA-00942 errors running on an Oracle db."

Ideally we should maintain our schema properly, using source control and configuration management best practices. In this scenario we know beforehand whether the schema we run our scripts against contains those tables. We don't get errors because we don't attempt to drop tables which don't exist.

However it is not always possible to do this. One alternate approach is to have two scripts. The first script just has the DROP TABLE statements, prefaced with a friendly

PROMPT  It is safe to ignore any ORA-00942 errors in the following statements

The second script has all the CREATE TABLE statements and leads off with

PROMPT  All the statements in this script should succeed.  So investigate any errors

Another option is to use the data dictionary:

begin
    for r in ( select table_name from user_tables )
    loop
        execute immediate 'drop table '||r.table_name
                    ||' cascade constraints';
    end loop;
end;

Be careful with this one. It is the nuclear option and will drop every table in your schema.

APC
Yeah, but say I don't appreciate condescending inapplicable comments, since this might only be used for a one-man-at-home-project to generate an initial ddl script for a small non-commercial example project that isn't subjected to CM. In this scenario you could avoid sounding like an ass by avoiding incorrect assumptions or just answering the given question. Sorry, I don't handle nerdy programmer snob attitudes very well.
Crusader
And you could preface your question with your implicit requirements and level of project sophistication, so that people who do tell you (and those who come behind you) how to properly engineer solutions won't be mistaken as condescending asses. Alternatively, learn to use `grep`, specifically the `-v` switch.
Adam Musch
A valid point, but a rude response (which has since, thankfully, been edited) is entirely under the control of the answerer regardless. Also grep on Windows, does not compute. The 'easy' answer I hoped for doesn't seem to exist, so it's probably not a problem worth solving?
Crusader