Doug Gschwind

Hi Kia,

This simply could be that the primary key of the object that you are trying to persist matches the primary key of an existing row. I assume you are using native sequencing? Take a look at the SQL that is generated at insert time. That should give you an indication that the sequence from which you are obtaining new primary keys has an overlap of existing primary keys.

By the way, the TopLink discussion forum (http://forums.oracle.com/forums/forum.jspa?forumID=48) has lots of answers to these, and far more complex issues. I highly recommend you peruse postings there as this forum seems primarily visited by Hibernate users. Additionally, the TopLink discussion forum is regularly visited and contributed to by both members of the TopLink product management and TopLink development teams at Oracle, and is free to post and read.

Hope that helps,

Doug

Adela,

I would have to see what you have in place for both the Data and the DataHistory descriptors in entirety to understand further. Instead, allow me to offer the following suggestions.

It seems clear that you have a need for both DataHistory and Data classes in your domain model. Seems also that your DataHistory class has two relationships of interest. One is a collection type to all of the Data instances that comprise the history in entirety. The other is the one to one relationship that represents the "current" Data instance for that DataHistory instance.

I would recommend a separation of concerns here and use two tables. If you had a DATA_HISTORY table, I can see the need for two columns, ID and VERSION, where the ID column is the lone primary key. The VERSION column can then be used for optimistic lock checking, but otherwise doesn't house any other business information.

If you then also had a DATA table, I can see the need for at least four columns there ID (primary key, orthogonal to DATA_HISTORY.ID), DATA_HISTORY_FK (points to DATA_HISTORY.ID), VALID_FROM (date not null), and VALID_TO (date). Probably no need for a VERSION column on this table since Data instances are immutable and a change to one really means adding a new instance to its history. That is if I understand your intent correctly.

In the descriptor for the DataHistory class, the one to many relationship that represents all of the Data instances can be set up to do some type of ordering and such. The "current" data instance, a one to one mapping, can be set up so that that mapping's selection criteria specifies where VALID_TO is null. You will of course have to keep that relationship up to date when a new Data instance is added to a DataHistory instance.

The descriptor for the Data class simply has the back pointing one to one relationship from the Data instance back to its owning DataHistory instance.

I think if you break those out that way, some of the complexity you described can be more easily managed.

-- Doug

I believe that the JDBC driver that you are using has the full implementation of each interface mandated by JDBC. Thus, when you load your JDBC driver (e.g. Class.forName(yourJDBCDriver) , that implementation becomes available to your Java runtime environment.
It is not something that you should have to implement unless you of course are implementing a JDBC driver yourself.

It sounds like the use of a hashtable doesn't fit your needs. You could either use an ordered collection (e.g. Vector) or if you still need keyed lookups, use a collection type that best fits your primary data lookup needs, then morph that collection into another form where it is used secondarily.

Can you post the segment of source code that depicts where your object is created as well as the point where you believe the reference is lost?

A concrete class is simply one that is not abstract.

Q: non static methods cannot be accessed by static methods?
A: Static (i.e. class) methods do not have an implicit object with which they are working, no notion of "this". A static method thus cannot call a non static (i.e. instance) method, UNLESS it has an object on which it can make the call. Thus, if a static method has a reference type available to it, e.g. Object obj, it can call an instance method on obj ... obj.toString().
An instance of a class can be used to call both static and non static methods of the class, given that visibility constraints are not violated.
In your example, printArgv() could be made a static method, and no instance of TestArrayPassing would need to be created. e.g.
public class TestArrayPassing
{
public static void printArgv(String [] argv)
{
// Do what you want here.
}
public static void main(String [] argv)
{
printArgv(argv); // Accomplishes same thing.
}
}

Your TestHelloMail class only has one method defined, but it is a constructor. When you create the instance of TestHelloMail (a), the constructor will be invoked. Thus, even if a.TestHelloMail() were able to be resolved via some magic, the constructor would get called twice.
I would recommend also that you not name instance or class methods the same as the class name, even though that is allowed. It helps to eliminate confusion I would argue.
To solve your compile problem, you can do a couple of things. Either remove the call to a.TestHelloMail(), or add a method to TestHelloMail.java. If you chose the latter, TestHelloMail.java would need to look something like:
public class TestHelloMail
{
public TestHelloMail()
{
// The constructor
...
}
public void TestHelloMail()
{
// Inclusion of return type makes this a method!
}
}

I would have to surmize that the depiction of exceptions within a Class diagram is not something that is part of UML as it was adopted as standard technology by the OMG.
I do know that at least one of the UML based OOA/OOD CASE tools (Together/J) does support the class designer in allowing thrown exceptions to be declared with the method signature. This information does not appear in the class diagram depiction (even if the level of information displayed in the diagram is set to implementation) however. It does of course get forward engineered into the Java source code and the javadoc compliant comment block as well.

Has anyone found the threshold that when exceeded forces you to require the use of double buffering in a JPanel? Since double buffering increases memory usage, I would like to only use it when certain hardware resources are lacking and thus induce "flickering" within single buffered JPanel instances.
Also, if a JPanel instance is a nested component within a higher level JPanel instance, should the double buffering policy be set consistently at all levels? e.g.
JPanel parent = new JPanel(true);
JPanel child = new JPanel(true);
parent.add(child);
Do we care about the double buffering policy of internal JPanels if the top level JPanel's double buffering policy governs all internal panels as well?

This problem was conceptually addressed in Smalltalk's Model-View-Controller (MVC). If you are not familiar with it, you might look into a detailed description of it. It essentially advocates the break down of class responsibilities so that you don't have business objects (the Model part) worrying about how to present (the View part) themselves.
In terms of a Java implementation, you would probably put your business objects into a separate package than the package(s) that contain your GUI (View and probably Controller) classes. That is certainly your scenario #1.
However, if you have data from that form where some is a logical fit for relating to other pieces of data on the form, but not all, you may find it easiest (and more appropriately a better OO model fit for that data and its behavior), to break that up into individual classes as well.
Hope this helps.

I have used Rose 98i and I believe you can select the package or classes of interest and "Web Publish" the design output for just the selected entities. I believe the "Generate for selected entities" or the like is an option on the Web Publishing dialog. Seems like I used that before. I would guess that if you did not select that option (assuming it exists), it generates the world for you.
Rose certainly has some strong points. However, I compared it in detail to Together/J (5 months ago) and Together/J was the superior product.

If your RDBMS will not support what you need, one thing you can do is add one additional column to the table(s) that need row level locking. That column can simply be a timestamp.
When the row is retrieved and inflated into an object, the timestamp is also retrieved. When the row is attempted to be updated, the where clause needs to be extended to indicate where the timestamp equals the value that was originally read. Also, the timestamp column needs to be updated as well upon success, but this simply extends the columns being updated.
The first update will succeed. Subsequent ones that have the old timestamp will not because the where clause will return zero rows. Kind of brute force, but this mechanism does work.

If both classes are to reside within the same package, then they must reside in the same directory. If they are to reside in different packages they cannot reside in the same directory and be successfully compiled. I will assume they are to reside in the same package.
If you have class Y in Y.java and class X in X.java, Y extends X, and they are in the same package, you need not use an import statement. Simply reference X from within Y.java. I would highly recommend that you do not reference Y within X.java though.
So you should have something like:
X.java
------
package SomePackage;
public class X
{
}
Y.java
------
package SomePackage;
public class Y extends X
{
void someOp(someargs)
{
X someX = new X();
}
}

I have a need in an application to allow an end user two ways to expand a collapsed node that exists in a tree view (JTree). For example, one way could be to simply click within the + square, and the other could be to simply double click on the node name. I also need to know which mechanism of the two was used to request the expansion. As far as I can tell though, there is only one callback mechanism for when the node is requested to be expanded.
I only need a single way to collapse an expanded node, and JTree already fully supports my needs in that regard.
Any ideas?