Skip to Main Content

Java Development Tools

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

BUG - Cannot copy materialized view to offline database - JDeveloper 11GP4

ow005960Sep 9 2008 — edited Sep 9 2008
I was trying to copy a schema with a lots of materialized views from into an off-line database whene I got this stack trace below

09-Sep-2008 08:09:36 oracle.jdbc.driver.T4CConnection assertLoggedOn
SEVERE: Throwing SQLException: 430
09-Sep-2008 08:21:47 oracle.ide.db.transfer.TransferManager prepare
SEVERE: Prepare failed
java.lang.IllegalArgumentException: No enum const class oracle.javatools.db.ora.MaterializedView$Staleness.IMPORT
at java.lang.Enum.valueOf(Enum.java:192)
at oracle.javatools.db.ora.MaterializedView$Staleness.valueOf(MaterializedView.java:175)
at oracle.javatools.db.ora.MaterializedViewBuilder._parseStaleness(MaterializedViewBuilder.java:378)
at oracle.javatools.db.ora.MaterializedViewBuilder.fillInBaseProperties(MaterializedViewBuilder.java:107)
at oracle.javatools.db.ora.MaterializedViewBuilder.fillInProperties(MaterializedViewBuilder.java:63)
at oracle.javatools.db.ora.MaterializedViewBuilder.fillInObject(MaterializedViewBuilder.java:54)
at oracle.javatools.db.AbstractDBObjectBuilder.buildObject(AbstractDBObjectBuilder.java:36)
at oracle.javatools.db.dictionary.DictionaryDBObjectBuilder.buildObject(DictionaryDBObjectBuilder.java:63)
at oracle.javatools.db.AbstractSchemaObject.checkInit(AbstractSchemaObject.java:168)
at oracle.javatools.db.AbstractSchemaObject.checkInit(AbstractSchemaObject.java:205)
at oracle.javatools.db.AbstractSchemaObject.copyToImpl(AbstractSchemaObject.java:64)
at oracle.javatools.db.ora.MaterializedView.copyToImpl(MaterializedView.java:378)
at oracle.javatools.db.ora.MaterializedView.copyTo(MaterializedView.java:367)
at oracle.javatools.db.AbstractDBObject.copyTo(AbstractDBObject.java:89)
at oracle.jdevimpl.offlinedb.transfer.OffToOffPolicy.copyForTransfer(OffToOffPolicy.java:181)
at oracle.ide.db.transfer.TransferManager.prepare(TransferManager.java:155)
at oracle.ide.db.transfer.TransferManager.prepareAndTransfer(TransferManager.java:374)
at oracle.ideimpl.db.transfer.TransferRunnable.run(TransferRunnable.java:79)
at oracle.ide.dialogs.ProgressBar.run(ProgressBar.java:615)
at java.lang.Thread.run(Thread.java:595)

Environment
Windows XP Professional
Studio Edition Version 11.1.1.0.0
Build JDEVADF_MAIN.OTN4_GENERIC_080429.0116.4949
Oracle IDE 11.1.1.0.22.49.49
java.runtime.version 1.5.0_11-b03

Database 10g R2 (10.2.0.3.0)

Comments

NickR2600-Oracle

So when would it be beneficial to have an abstract method in a super class? One answer would be because the sub classes have no shared functionality. Or in other words, because the functionality is so different between subclasses. Or because the functionality can't be defined yet.

In Java Puzzle Ball, I have an abstract class called GameObject. It's inherited by a lot of different concrete classes: bumpers, assignable behaviors, level geometry... And one if its responsibilities is to define what happens when a collision occurs. But I have to leave the collision effect method abstract. The geometry of all these objects are so dramatically different, there isn't any shared functionality I can write to define how the physics of all these different angles and shapes should work. The best I can do is write an abstract method as a promise to implement the functionality somewhere later down the inheritance structure.

pastedImage_0.png

AjayKumarGuttikonda

Thank you so much for taking time out and answering the question in very elaborated manner. I understand, the conclusion is Account class need not be abstract as all methods are implemented and also there is no problem Account class being abstract as the abstract class by definition can have all methods implemented. Can you please also explain why in this case it is beneficial to have Account class as abstract since we have implemented all methods.

NickR2600-Oracle

You got it.  I'm glad you're enjoying the course

It's more of a design choice in this example.  Even though Account could technically exist as a concrete class, I only meant for it to be a container for all the fields and methods shared by savings and checking accounts.  So to reinforce that decision and prevent instances of Accounts from getting created, the class is left abstract.

One other thing to consider is that Accounts don't have an accountType field, but savings and checking account classes do.  Looking back, maybe I should have written an abstract method into the Account class to somehow enforce the need for this field.

1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Oct 7 2008
Added on Sep 9 2008
1 comment
472 views