Re: Question about JPublisher ...

From: Robert Klemme <shortcutter_at_googlemail.com>
Date: Mon, 05 Sep 2011 20:40:42 +0200
Message-ID: <9ckjdiFaj7U2_at_mid.individual.net>


On 04.09.2011 20:03, Andreas Leitgeb wrote:
> Robert Klemme<shortcutter_at_googlemail.com> wrote:

>> On 09/02/2011 04:55 PM, Andreas Leitgeb wrote:
>>> 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
>> Just guessing here: both records have the exact same structure
>

> 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

That wasn't obvious from your first posting.

>> maybe JPublisher is figuring that both are structurally equivalent
>> and lumps them together.
>

> 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?

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

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

> 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.

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.

> PS: but thanks, anyway, for answering.

You're welcome!

Kind regards

        robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Received on Mon Sep 05 2011 - 20:40:42 CEST

Original text of this message