db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Burns" <jamie_r_bu...@hotmail.com>
Subject Re: reverse db tools status
Date Wed, 22 Jan 2003 23:37:38 GMT
> Unfortunateyl reversedb doesn't work that well, there are problems with
> mysql, mssql and postgres and reading a schema from oracle is really slow.

I have had a number of problems matching Oracle types to JDBC types and Java
types. I think the static Utilities class should be replaced with an adapter
that returns the correct mappings for the database based on the underlying
database system. We could either use the getDatabaseXXX() methods of
DatabaseMetaData to choose the best adapter or put the onus on the user to
choose one - perhaps a list of available ones could be put into
OJB.properties. If we went with an adapter it would implement a simple
interface like

    public String getJavaType(String databaseType);
    public String getJDBCType(String databaseType);

Another feature l had problems with was the conversion of column names to
bean names. I was stuck with a database with column names like ED_ED_ID
which got converted to eD_ED_ID and table names like AGENT_TYPES which got
used as

public ...Agent_types aAgent_types
...
public Agent_types getAAgentTypes()

Im working on something that will do a better job of making names that
conform better to the bean spec and common Java naming conventions. So far
it is working for most cases l can think of. However, l think this should be
done as an adapter so that users can plug in their own if they have a
special case. Again, it could implement a simple interface like

public String toClassName(String name);
public String toAttributeName(String name);

The available implementations could be put into OJB.properties.

One of the JDBC Types is BOOLEAN. Most bean users would expect a set/is
pair. Does OJB handle this or does it expect set/get for booleans?

> > I think we agree on decoupling the ui and the core functionality. This
is
> > important because it can benefit, for example, various plugin writers.

I agree too.

> I will try to integrate your changes into CVS over the weekend. But we
> should focus the effort on reversedb2. Maybe you'd like to have a look at
> the code before we discuss this.

Ok. I am not familiar with reversedb2. Same documentation excuse as Anthony.

> > Also some bugs are just found:
> >
> > In the output schema xml
> >
> > 1) The field ids are not in consecutive orders and so may cause
> > errors with
> > 0.9.8. I heard someone is working to allow "holes" in the ids,
> > but i do not
> > know the status. May need or need not to fix depending on this?

I also has a problem with the ids starting at zero. Seemed to go away when l
changed them all by one.???

I had problems with tables that contained 2 FK's to another table.

CLIENTS
-----------
CLIENT_ID


EPISODE_DETAILS
-----------------------
CLIENT_ID (FK to CLIENTS.CLIENT_ID)
ORIGINAL_CLIENT_ID (FK to CLIENTS.CLIENT_ID)

The tool only created one Clients attribute in EpisodeDetails instead of 2
and gave the repository.xml entry 2 FK's for the Clients attribute in the
definition of EpisodeDetails.


This is my first time using OJB. I spent a week sorting out reverse
engineering issues and came really close to dumping the whole idea of using
it. OJB looks like it has potential. I think we can give it a boost if we
give first time users a nice reverse db tool to get them started.


Mime
View raw message