This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 101719 - Entity from EntitiesFromDBGenerator is not immediately in the model
Summary: Entity from EntitiesFromDBGenerator is not immediately in the model
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Andrei Badea
URL:
Keywords:
Depends on: 108649
Blocks: 93050
  Show dependency tree
 
Reported: 2007-04-19 10:21 UTC by Jan Stola
Modified: 2009-05-26 20:52 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Stola 2007-04-19 10:21:32 UTC
The information about the entity generated by the EntitiesFromDBGenerator is 
not immediately in the model. Moreover, there is no clean way to wait for the 
entity to appear in the model.

The enity should either appear in the model immediately or there should be some 
listener or wait method.
Comment 1 Jan Stola 2007-04-20 08:31:35 UTC
IMHO the current implementation (where the model is notified about a new entity 
via detour through Retouche) is not ideal. I would prefer a solution where the 
generator notifies the model about the changes directly. It would significantly 
improve the performance of Matisse-related use-cases. I am also afraid that the 
current implementation will not work well if the entity is created when 
Retouche is busy (e.g. scanning JDK or project).
Comment 2 Andrei Badea 2007-04-20 16:57:58 UTC
Right, I am currently considering either waiting for Retouche to compile the
file, or introducing a method like ensureTypeScanned() somewhere in the model
which could be used to notify that a type needs to be scanned and added to the
model.

Re. busy Retouche: that is probably a problem no matter which approach is
chosen. I want to avoid calling JavaSource.runUserActionTask() while scanning,
even if I go the notification way.

By the way, you should avoid using the model if it's not ready (which it will
claim is not during a scan). There is no API for that yet, but I plan to add one
after M9. MetadataModel.isReady() or something like that, and also
MetadataModel.waitReady() or such. You will need to use these methods in your
wizard (and avoid entering the model context in the AWT thread, which you are
currently doing).
Comment 3 Andrei Badea 2007-06-19 10:37:42 UTC
This requires some changes in the Java infrastructure, not for M10. When these changes are implemented, the right way to
ensure that the entity classes are in the model will be to use MetadataModel.runReadActionWhenReady() instead of
runReadAction(). This methods waits for the classpath scan to finish, so you need to use it consistently everywhere.
Comment 4 Erno Mononen 2007-06-29 14:04:31 UTC
There is a similar issue in the EJB model, adding an EJB annotation to a newly created class does not make it appear in 
the model even if you use the runReactionWhenReady method.
Comment 5 Andrei Badea 2007-10-02 14:19:07 UTC
Marking as enhancement to match issue 108649, which this depends on. Still planning to fix after beta 2.
Comment 6 David Konecny 2009-05-24 23:47:26 UTC
Is this still valid issue or not? I'm trying to figure out whether something needs to be done for next release but
looking into code everything seems to be working well: api.java.source.ClassIndexListener changes are fired immediately
after a changed source was saved; and MetadataModel.runReadActionWhenReady can be used to run something after scanning
was completed. Can anybody say what's still missing or broken? Thanks.
Comment 7 Tomas Zezula 2009-05-25 09:41:41 UTC
Cau Davide,
the problem should be fixed. In the NB 6.0-6.5 there was a delay between save and update, because of timestamps. In the NB 6.7 i've rewritten to use other 
timestamp storage and there is no more such a delay.
Comment 8 David Konecny 2009-05-26 20:52:06 UTC
Thanks Tomas. It looked like that.