Support Questions
Find answers, ask questions, and share your expertise

Oozie - Is it OK to modify its database?

Oozie - Is it OK to modify its database?

Explorer

hi
​We've got the following error:

org.apache.openjpa.persistence.PersistenceException: ERROR: value too long for type character varying(255)
​{prepstmnt 190305649 INSERT INTO WF_JOBS (id, app_name, app_path, conf, created_time, end_time, external_id, group_name, last_modified_time, log_token, parent_id, proto_action_conf, run, sla_xml, start_time, status, user_name, wf_instance) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)} [code=0, state=22001]

and to solve it we've altered the WF_JOBS table, resizing the app_path and app_name to be varchar(1024).

Is it acceptable to modify the oozie database?

Will it cause us problems in other parts of oozie?

We did while using postgreSQL for oozie db.

Thanks

Doron

2 REPLIES 2

Re: Oozie - Is it OK to modify its database?

Rising Star
Doron,

We generally do not suggest to directly modify the oozie database schema as a future upgrade may further modify this column, table, and that statement may fail due to previous modification. In this case, it sounds more likely that your workflow path was greater than 256 characters, unless you named your workflow something greater than 256 characters. Would you be able to relocate your workflow to a shorter directory? If I can reproduce, I'll open an improvement jira upstream to support a very long directory or application name.

Thanks,
Robert Justice


Robert Justice, Technical Resolution Manager


Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.

Learn more about the Cloudera Community:

Terms of Service

Re: Oozie - Is it OK to modify its database?

Explorer
Robert thanks for your reply.
Indeed, I fear the exact issues you mentioned of future upgrades of this DB.
However the names of the workflows are generated by some code of ours and they tend to become very long - more than 256.
I'm trying to convince or development team to shorten this but it will take them time.

Now - except for future changes in the database - could it be that other parts of oozie might be affected? some code that reads this table and has hard-coded 256 arrays size instead of strings?

If there is no such issue, we'll go with our modification - we did the following:
ALTER TABLE wf_jobs ALTER COLUMN app_path TYPE varchar(1024);
ALTER TABLE wf_jobs ALTER COLUMN app_name TYPE varchar(1024);

I do hope you can reproduce the issue and recommend this change. :)

Thanks
Doron