[Tablegen-development] Re: Status of TableGen 1.10

[Joseph C. <Jos...@ma...>]

Hi Rob,

Uploading as tablegen seems fine to me.
I've picked up tablegen-new via the CVS, but I've not really played yet.

We should consider placing Bret binaries under our CVS so we can do a single
download from our CVS tree without having to obtain from multiple source
to get off the ground - what do you think?

Handling the joins, binary data etc all sound good - long standing TODOs :-)

There is a good case for give getAddress() type naming, but there is an
potential issue.
There may namespace problems, as some people with inevitably use names which
will clash with our "standard" names (e.g. ones in the base class).
I had a version which allowed you to insert an optional prefix to help with
that.
Offhand I would be inclined to agree and ditch the ByIndex - if any for
esthetic reasons :-)

If you want caching I'd add code to auto generated a cached subclass. There will
be occasions - often? - where the user will not want to cache, and there is
plenty of
problems especially with fast changing data. I'd not put it directly in the core
auto-gen'd class. Make sense?

Wouldn't worry about method naming - I reckon we start at v2.0 as the changes
are significant, and it makes it clear it's a new development - seen as it's
been
quiescent for over a year.

EJB makes sense - I'd stopped active development just as they were becoming
available (free ones anyway!) - but it's obvious that's where it would be
useful.
Longer term, I'd like to make some of these general purpose GUI tool beans
which can be imported into tools such as Forte. Good for RAD work then.

Arrays not Vector is a definite yes - especially as my recently playing with
beans
has shown using vectors for this kind of thing is a mistake.

The missing statement closes are bugs. I think I missed most of those
as I generally use mysql which doesn't really care :-)
I think I'd better start testing against postgresql as well!
Hmmm that's another job - could do with a decent set of tests, as I found
there were a fair amount of bugs due to differences in the JDBC drivers.
Like, err, err handling lots of connections and queries... <grin>.

Joe








"Robert Ratcliff" <rob...@th...> on 12/08/2000 16:44:36

Please respond to rob...@th...
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:                                                          
                                                              
 cc:      joe...@vi...(bcc: Joseph Carter/MAIN/MC1)  
                                                              
                                                              
                                                              
 Subject: Status of TableGen 1.10                             
                                                              








Hi Joe,

  I just wanted to give you an update on TableGen 1.10. I've merged
two of the major changes you gave me into 1.08. The first one
was the ability to use the new ewin pooling package. The second one
was from the guy at Novell which allowed java naming conventions
and lots of formatting changes. The second "patch" had lots
of bugs in it and so I spent most of the time getting 1.10 to work
again after all the changes. It seems to work for the few number
of tests I've run on it now. I uploaded a test version to
sourcegen as tablegen-new. I'll probably go ahead next week
and upload it as tablegen (unless you have other suggestions.)

I also created a mailing list on SourceForge called tablegen-development.
I haven't tried it out but they claim that its ready to go.

I'm going to spend one more day adding a few more constructors to the
wrappers and if I get time I'd like to add prepared statements to
at least the insert and update functions to handle some binary
data we'll have in our application. Ideally I'd like to add
the capability to handle a joined dataset and automatically
create the object tree by splitting out the data from the joined
result set.

Also, I had a few questions for you in regards to method names.
I'd like to make child objects accessible by just calling their
name such as:

     Person person
          String lastName
          Address address
          Role role

you'd access address by using person.getAddress() instead of
person.getAddressByIndex()
It seems to me that the application programmer doesn't need to know what
you're doing underneath the covers. Whether you're getting a primitive or
a child object shouldn't matter to the user even though you might
be doing an additional database lookup to get the object. Also I was
thinking
of adding a class variable for each child object and a check in the
getAddress() method for instance to see if the address had already been
retrieved. Anyway, do we have to worry about keeping all the method name
conventions
the same? How many users are there of TableGen? I usually don't worry a
whole
lot about backward compatibility until things have stabilized more,
especially
if the end product would be better.

At some point I'd also like to add the capability to have EJB methods
generated for bean managed persistence.

Also, what would you think about replacing the Vector return type with an
Array
instead for the "get" methods that return more than  one object. I could
also
add additional methods that had names like getAllObjectsAsArray. Arrays of
objects are just much easier to code with..no casting, no instance of
checking,
and very simple access to the elements of the Array (no enumeration.)
Its too bad that you can't have methods with the same name and prototype
return
different object types. Do you have a strong opinion on that?

There are also a number of places where the result sets and the statements
aren't being closed. This has been causing the out of cursors errors
in Oracle and such. It appeared that the .disconnect() method was supposed
to handle that but only if you use the class variables for resultSet and
statement.
Was there a reason those weren't used or were you thinking that'd be best
to just close the statements right after the query?

Let me know what you think.

Talk to you soon,

Rob