Project

General

Profile

Actions
Copy link

Bug #1307

closed

Multiple relations to a Dbo with a composite key issue

Added by Saif Rehman over 12 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Koen Deforche
Target version:
3.2.3
Start date:
05/28/2012
Due date:
% Done:

0%

Estimated time:

Description

Hello,

I have been encountering this problem for a long time and I have even posted on the forums to report this issue however it was not recognized by anyone, therefore, I thought I should report it as a bug as it one.

When more than 1 relations either ManyToOne or OneToOne to a Dbo which has a composite key are created then setting different column names for each column becomes impossible or very difficult.

To explain this I am uploading a very simplified test case to reproduce the error. If any more detail about the test case is required please reply to this issue and I will get back to you. I am not sure but I believe maybe allowing the use of joinIds on ManyToOne and OneToOne relation should be able to resolve this issue.

I hope some one checks and resolves this issue.

Thank you.

Files

DboTestSaif.C (8 KB) DboTestSaif.C Saif Rehman, 05/28/2012 08:57 PM
Actions
Copy link
 #1

Updated by Koen Deforche over 12 years ago

  • Status changed from New to InProgress
  • Assignee set to Koen Deforche

Hey,

Thanks for the simplified test case, I'll have a look at it ASAP.

Regards,

koen

Actions
Copy link
 #2

Updated by Saif Rehman over 12 years ago

Can you please take a look at it :)

Thank you.

Actions
Copy link
 #3

Updated by Koen Deforche over 12 years ago

  • Target version changed from 3.2.2 to 3.2.3
Actions
Copy link
 #4

Updated by Koen Deforche over 12 years ago

  • Status changed from InProgress to Closed

Hey,

The problem is that you are creating duplicate names because when specializing field() you should (almost) always concatenate the given field with your 'internal' field names:

Thus:

void field(Action &action, ConfigurationKeys &Keys, const std::string &name, int size = --1)

{

field(action, Keys.Name, name + "_Name", 255);

belongsTo(action, Keys.ModulePtr, name + "Module", Wt::Dbo::OnDeleteCascade | Wt::Dbo::OnUpdateCascade | Wt::Dbo::NotNull);

field(action, Keys.Type, name + "_Type");

}

However, when doing that, Wt will complain that you are not creating consistent back-collections for several of your fields.

Find in attachment a fixed version with the following output:

begin transaction
create table "modules" (
  "id" integer primary key autoincrement,
  "version" integer not null,
  "Name" varchar(255) not null,
  "VersionMajor" integer not null,
  "VersionMinor" integer not null,
  "VersionFix" integer not null,
  "Revision" bigint not null
)

create table "configurations" (
  "version" integer not null,
  "Id_Name" varchar(255) not null,
  "Id_Module_id" bigint not null,
  "Id_Type" integer not null,
  "Title" text not null,
  "Details" text,
  "RestartRequired" boolean not null,
  "ExpertWarning" text,
  primary key ("Id_Name", "Id_Module_id", "Id_Type"),
  constraint "fk_configurations_Id_Module" foreign key ("Id_Module_id") references "modules" ("id") on update cascade on delete cascade
)

create table "configurationenums" (
  "version" integer not null,
  "Id_Configuration_Id_Name" varchar(255) not null,
  "Id_Configuration_Id_Module_id" bigint not null,
  "Id_Configuration_Id_Type" integer not null,
  "Test1_Id_Name" varchar(255) not null,
  "Test1_Id_Module_id" bigint not null,
  "Test1_Id_Type" integer not null,
  "Test2_Id_Name" varchar(255) not null,
  "Test2_Id_Module_id" bigint not null,
  "Test2_Id_Type" integer not null,
  primary key ("Id_Configuration_Id_Name", "Id_Configuration_Id_Module_id", "Id_Configuration_Id_Type"),
  constraint "fk_configurationenums_Id_Configuration" foreign key ("Id_Configuration_Id_Name", "Id_Configuration_Id_Module_id", "Id_Configuration_Id_Type") references "configurations" ("Id_Name", "Id_Module_id", "Id_Type") on update cascade on delete cascade,
  constraint "fk_configurationenums_Test1" foreign key ("Test1_Id_Name", "Test1_Id_Module_id", "Test1_Id_Type") references "configurations" ("Id_Name", "Id_Module_id", "Id_Type") on update cascade on delete cascade,
  constraint "fk_configurationenums_Test2" foreign key ("Test2_Id_Name", "Test2_Id_Module_id", "Test2_Id_Type") references "configurations" ("Id_Name", "Id_Module_id", "Id_Type") on update cascade on delete cascade
)

commit transaction

Btw, you are really making this hard on yourself this way. Some people will argue that you should never use composite IDs. While I believe there are justified reasons to use them sometimes, I think your example is not one of them.

Several popular ORMs, including for example the one in Django, do not even support composite IDs at all...

Regards,

koen

Actions
Copy link
 #5

Updated by Saif Rehman over 12 years ago

Thank you for replying. Could you please tell me a way to keep unique elements like in my schema without using composite keys.

Thank you :)

Actions
Copy link
 #6

Updated by Koen Deforche over 12 years ago

Hey,

Currently you can't specify this in the schema generation by Wt::Dbo (it has been requested a few times, but the current feeling is that whatever we implement it will not be satisfactory).

What you should do is compelement the schema created by Wt::Dbo with your own fine tuning:

  • adding indexes where you want
  • setting unique constraints where you want

You can do that from within your Wt application using Session::execute()

Regards,

koen

Actions
Copy link

Also available in: Atom PDF