We've got a pl/sql package, which defines a couple of records:

create or replace package foo.bar is
type snafu is record (
sf_col1 varchar2(42),
);
type blarg is record (
bg_col1 varchar2(42),
);

We use JPublisher to create Java classes for this package, and
*sometimes* it (unrequestedly) merges two of the records into
one (Java-)class, which then has (e.g.) both sfCol1 and bgCol1.

When this happens, the created plsql_wrapper.sql also shows
those merged records - so whatever goes wrong, it seems to go
wrong right at the start...

How does JPublisher extract the information from the DB, that it
needs to create its output? And what could cause it to "randomly"
merge records?

PS: oracle 10.2.0

On 09/02/2011 04:55 PM, Andreas Leitgeb wrote:
Just guessing here: both records have the exact same structure (i.e.
same order of elements with identical types) - maybe JPublisher is
figuring that both are structurally equivalent and lumps them together.

Side note: I would at least consider whether it's a good practice to
define two types with identical structure because they *are* equivalent.

Kind regards

robert

Robert Klemme <shortcutter (AT) googlemail (DOT) com> wrote:
Sorry, this guess didn't hit.
One of the structures has 59 elements, the other has 61 elements,
and the Java struct (as well as the one in plsql_wrapper.sql) has 120

Even if it *were* so, it wouldn't then make sense to lump them together
such, that all the duplicate elements among the actual db records
would then show up *doubly* in the created structs, would it?

Even though merely theoretical, I do not agree to that position.
If they have a different use, then they may easily have a different
future, too. If you merge them now, you'll likely have to re-separate
them, if one of the uses needs a change, lateron. Also, the fields may
mean different things (despite being of same types) and probably reflect
their specific meaning by different field names. Replacing two such
structures with a single one (with generic or misleading names then),
is most likely a bad idea.

PS: but thanks, anyway, for answering.

On 04.09.2011 20:03, Andreas Leitgeb wrote:
That wasn't obvious from your first posting.

No, but it could be a bug in a corner case.

Yeah, I considered that as well that's why I didn't write "it's bad
practice" but rather "consider whether it's a good practice". More like
a warning sign.

You're welcome!

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Robert Klemme <shortcutter (AT) googlemail (DOT) com> wrote:
Indeed, I didn't (and still don't) find this information relevant.
JPublisher adds a wrong record's fields to the wanted record's fields,
so it didn't occur to me that this could possibly be a buggy attempt
at *unifying records* in the first place.

As it happened, the two original records even had two fields in common
(same field name and type in both records, the other fields being
different), and these two showed up doubly in the generated Java class,
which caused the Java compiler to barf on it, which again made us notice
it, because we didn't actually use this particular record. (it only gets
generated as a byproduct when we need other parts of that plsql-package)

I had hoped for someone recognizing some bug of JPublisher (and perhaps
the oracle-release by which this would be fixed).
Googling (and I did a lot of it) didn't show anything relevant, but then
again, Google doesn't seem to have oracle's bug-database in its index.