Created attachment 91456 [details]
tool

Created attachment 91457 [details]
JUnit test

I'm sorry I see no relation to DB tooling code in IDE, in these tests. It seems as a generic problem, or Eclipse Persistence library, I don't know. In any case, nothing to fix in DB support in NetBeans. Reopen it if I'm wrong. Thanks

Aren't the database to entity a netbeans wizard? The generated classes are wrongly generated.

Have anything been done to fix this? I'm not seeing the issue on Build 200911241400.

Closing it since it works for me in latest build.

I had to recreate this classes a couple of times in the same package (after deleting the previous ones) and I got the issue again. The issue is a lot better now since this used to happen 100% of the time and now is like 20% but still needs fixing.

As soon as it starts it'll happen 100% of the times. I tried deleting the var folder without luck.

>  The generated classes are wrongly generated.

Hi, do you have an idea what is wrongly generated? What should be different - can you please send a diff of the IDE-generated vs. the correct version.

Based on the latest comments, is this still a code generation issue, or a runtime issue? Sorry I did not have time to try your exact example yet.

The issue is at generation. Basically relationships (@Join) are generated multiple times. I'll attach an example later today with the diff you request.

Created attachment 92008 [details]
Diff file

Here's the diff requested.

We may want to fix in a patch, this looks quite nasty. Bumping to P2.

from first attempt got correct joins without duplication,
    @JoinColumn(name = "author_id", referencedColumnName = "id")
    @ManyToOne(optional = false)
    private User authorId;
    @JoinColumn(name = "test_id", referencedColumnName = "id", insertable = false, updatable = false)
    @ManyToOne(optional = false)
    private Test test;

Any ideas on how to get state with wrong generation? As I see if was opened...closed.. reopened, it may be hard to reproduce so any ideas are welcomed.

javydreamercsw,
can you generate db schema at time you are getting this error. it may be good to verify if schema/database contain duplicating foreign keys.

If my assumption is right I can try to filter out duplicating keys as there was also request for this before (but  can't find the issue) 
but the main issue may be in appearance of duplicate fk (may be it's something in eclipselink). 
Also I can create sample schema and modify to contain duplicate fk to test a fix but it may be not the same as in issue.

In the first posts you can see someone was able to duplicate it from the sql file already attached. I don't have the sources right now. If unable to reproduce let me know so I can attach those later.

just sql create with entities generation works fine for me, if it was an issue (duplication of fk after some action) in some old build of eclipselink it may be hard to reproduce now if it was fixed. I'll push my draft fix but with commented invocation for now before someone will be able to reproduce it and/or will be able to provide db schema for this case (to generate schema use Persistence|Database Schema wizard) as it may be another issue rather then fk duplication.

javydreamercsw, what post do you reference? may be I miss something but see fist one is yours.

//
revert to P3 for now as I can't verify my fix and have no reproducible steps. may need to be reevaluated near 6.9 release dates.
Petr, Is it ok for you?

http://hg.netbeans.org/web-main/rev/e1487db8b6cb

Just today I was able to reproduce it with latest dev build (201001131418). I'll attach two schemes, the one for the original issue and today's one.

Created attachment 93267 [details]
Original Schema

Is the same schema, my bad.

thanks, there was test_case before with the issue, what table should be used from this schema?

ok, I found myself, I see duplicates with strange names like "fk_{some code}".
my fix seems to be working, 
pushed http://hg.netbeans.org/web-main/rev/0ce5b21a606e
it will correct behavior on generation side for corrupted schemas, but there is an issue why this duplicates appears. 
it may be either the issue in db schema generation  or some issue with persist operations in eclipselink/database/jdbc driver/generated nb code. Can you verify with some db tool if db contain duplicates too?

What kind of duplicate I'm looking for in the db? Relationships? Foreign keys?

foreign keys, 
for example I see one in nb in project tree in schema inside "Xinco.dbschema|Xinco|xinco_add_attribute|Foreign Keys" node.

Hmmm... This is the sql to create that table. One should be a constraint and the other the actual foreign key:

CREATE  TABLE IF NOT EXISTS `xinco`.`xinco_add_attribute` (
  `xinco_core_data_id` INT UNSIGNED NOT NULL ,
  `attribute_id` INT UNSIGNED NOT NULL ,
  `attrib_int` INT NULL ,
  `attrib_unsignedint` INT UNSIGNED NULL ,
  `attrib_double` DOUBLE NULL ,
  `attrib_varchar` VARCHAR(255) NULL ,
  `attrib_text` TEXT NULL ,
  `attrib_datetime` DATETIME NULL ,
  PRIMARY KEY (`xinco_core_data_id`, `attribute_id`) ,
  INDEX `xinco_add_attribute_FKIndex1` (`xinco_core_data_id` ASC) ,
  CONSTRAINT `fk_{DEA334D0-7F8F-4E6B-81EA-671A6C493FCC}`
    FOREIGN KEY (`xinco_core_data_id` )
    REFERENCES `xinco`.`xinco_core_data` (`id` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
PACK_KEYS = 0
ROW_FORMAT = DEFAULT;

xinco_core_ace is a better example:

CREATE  TABLE IF NOT EXISTS `xinco`.`xinco_core_ace` (
  `id` INT UNSIGNED NOT NULL ,
  `xinco_core_user_id` INT UNSIGNED NULL ,
  `xinco_core_group_id` INT UNSIGNED NULL ,
  `xinco_core_node_id` INT UNSIGNED NULL ,
  `xinco_core_data_id` INT UNSIGNED NULL ,
  `read_permission` TINYINT(1) NOT NULL ,
  `write_permission` TINYINT(1) NOT NULL ,
  `execute_permission` TINYINT(1) NOT NULL ,
  `admin_permission` TINYINT(1) NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `xinco_core_ace_FKIndex1` (`xinco_core_user_id` ASC) ,
  INDEX `xinco_core_ace_FKIndex2` (`xinco_core_group_id` ASC) ,
  INDEX `xinco_core_ace_FKIndex3` (`xinco_core_node_id` ASC) ,
  INDEX `xinco_core_ace_FKIndex4` (`xinco_core_data_id` ASC) ,
  CONSTRAINT `fk_{A5B19221-5358-4C98-82CC-581CD695C068}`
    FOREIGN KEY (`xinco_core_user_id` )
    REFERENCES `xinco`.`xinco_core_user` (`id` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_{BE5919E0-4B49-4754-861D-E7834EB59238}`
    FOREIGN KEY (`xinco_core_group_id` )
    REFERENCES `xinco`.`xinco_core_group` (`id` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_{8CCF024C-2E44-468D-B847-EF00897639E3}`
    FOREIGN KEY (`xinco_core_node_id` )
    REFERENCES `xinco`.`xinco_core_node` (`id` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_{4F26567D-38D8-4210-86D6-524AE418D6EB}`
    FOREIGN KEY (`xinco_core_data_id` )
    REFERENCES `xinco`.`xinco_core_data` (`id` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
PACK_KEYS = 0
ROW_FORMAT = DEFAULT;

I'm asumming your change made it to today's dev build (201001140201). If it did I noticed the following issues:

1. If the exception generated by the (controller) wizard are present when the controllers are generated an exception occurs (saying that x exception couldn't be found). I used to this always but it started failing in this build.

2. The duplicate is worst now. (Check XincoWorkflowState)

3. Detected further issues in the controller classes. (incompatible type errors within generated code)

Let me know if I need to open new issues for #1 & 3 or wait for a new dev build before doing it.

it's not yet in main repository, neither latest commit nor previos.
fail shouldn't be related to this change.

as you said you have both - constraint and foreign key, it may mean db schema generation handle constraint as fk and the issue may need to b evaluated on db|schema side also.
have you tried mysql admin tools to see db structures from mysql point of view?

Can't say about 1,3, is it easily reproducible in new project?

I agree that dbschema generation need to take a look. I generate MySQL generation schema from MySQl Workbench and such. Everything looks fine on the MySQL side.

And yes, 1 and 3 are easily reproducible.

ok, generation fix may not be in build yet, hope it will be integrated in 1-2 days.
can you file an issue for db|schema?
also feel free to file for 1,3 as it sems unrelated to the fix.

Integrated into 'main-golden', will be available in build *201001150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e1487db8b6cb
User: Sergey B. Petov <sj-nb@netbeans.org>
Log: fix #177341 - remove duplicate keys, invocation is commented for now

Created attachment 93325 [details]
gestures file

On latest build (201001150201) the generation stops when creating the XincoWorkfLowItem and then throws the attached error. I'm unable to verify on this build.

I was able to create from DB schema without problems (the issue is still present but I was able to complete the process).

I generated issue #179546 for the schema and updated #177122 for the others.

do you use sql from issue 179546?
error seems to be the same as in issue 173028.

got number of errors, trying to create xinco from sql:
Executed successfully in 0 s, 0 rows affected.
Line 845, column 1

Error code 1064, SQL state 42000: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET ' at line 22
Line 847, column 1

Error code 1064, SQL state 42000: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'htm' at line 1
Line 1071, column 158

etc.

tried to generate all tables from successful sql part and got no assertion, but the issue issue 173028 is random and it may be ok, is it always reproducible for you?

Error is the same but the focus on issue #179546 is the schema issue. Which sql are you using (from which issue) so I can update that one? The other issue (issue #173028) is in fact the same (feel free to mark mine as duplicate) and does happen randomly. I removed the var folder and Haven't seen it since.

>Which sql
>are you using (from which issue)
issue 179546

Fixed the referenced issue sql file.

thanks, will look a bit later, so finally if consider 173028 as random, was you able to generate entities later without duplicates?

I consider it a constant issue.

did I get it right, in your case assertion is thrown always?

Yes!

Tried fixed sql and as I see there is no invocation of code with assertion, looks like some relation is missed from xinco sql script.

What you mean by "code with assertion"?

Assertion is thrown from nb code for addition relationships(see you gesture attachment, <method>generateRelationship</method>) between entities
 if something was broken on entities generation step(may be entity wasn't generated or was generated but wasn't added to project classpath yet), but in case of generation from sql script for xinco I found no invocations of this code at all, will recheck today as I see there are a lot of foreign keys in xinco tables, may be I miss something.

anyway, looks like script in 179546 isn't related to assertion as assertion points to com.bluecubs.xinco.workflow.persistence.XincoWorkItemHasXincoState but I don't see anything with "XincoWorkItemHasXincoState" or even just "state" in the script.

I updated the referenced file on 2010-02-03 07:48:59 Not sure if you got that one.

Created all tables without modifying the script. Notice that the script creates 2 schemas. You need to create entities from xinco_workflow schema.

may be I miss a point, so finally what issue block verification? is it filed?

I couldn't figure out what you meant with your last comment.

do you have duplicate keys in recent builds? 
or you can't generate entities because of some new/old exceptions/issues etc.

I tried it on build 201002120200 successfully. I couldn't find any duplications!

consider as fixed then, feel free to reopen if I've missed something