Hi,

Could you please provide some insight into a problem we are having re: multiple relations between 2 entities?

OrganisationalUnit is an OrganisationalObject (1:1) using PK to PK. OrganisationalUnit contains many OrganisationalObjects (1:M) to FK OUId in OO.

We are having a problem where the 2 relationships have the same property name? Resulting in a compile time error?

LLBLGen Pro version: 2.6.8.709 Template: Adapter .NET 3.5 Database: SQL Server 2005

In class OrganisationalUnitRelations ...

public virtual List<IEntityRelation> GetAllRelations()

        {

              List<IEntityRelation> toReturn = new List<IEntityRelation>();

              toReturn.Add(this.OrganisationalObjectEntityUsingOrganisationalUnitId);

              toReturn.Add(this.OrganisationalObjectTypeHidingEntityUsingOrganisationalUnitId);

              toReturn.Add(this.OrganisationalUnitEntityUsingParentOrganisationalUnitId);

              toReturn.Add(this.SiteEntityUsingOrganisationalUnitId);

              toReturn.Add(this.OrganisationalObjectEntityUsingOrganisationalUnitId);

              toReturn.Add(this.OrganisationalUnitEntityUsingOrganisationalUnitIdParentOrganisationalUnitId);

              return toReturn;

        }

...

public virtual IEntityRelation OrganisationalObjectEntityUsingOrganisationalUnitId

        {

              get

              {

                    IEntityRelation relation = new EntityRelation(SD.LLBLGen.Pro.ORMSupportClasses.RelationType.OneToMany, "OrganisationalObject" , true);

                    relation.AddEntityFieldPair(OrganisationalUnitFields.OrganisationalUnitId, OrganisationalObjectFields.OrganisationalUnitId);

                    relation.InheritanceInfoPkSideEntity = InheritanceInfoProviderSingleton.GetInstance().GetInheritanceInfo("OrganisationalUnitEntity", true);

                    relation.InheritanceInfoFkSideEntity = InheritanceInfoProviderSingleton.GetInstance().GetInheritanceInfo("OrganisationalObjectEntity", false);

                    return relation;

              }

        }



        ...

public virtual IEntityRelation OrganisationalObjectEntityUsingOrganisationalUnitId

        {

              get

              {

                    IEntityRelation relation = new EntityRelation(SD.LLBLGen.Pro.ORMSupportClasses.RelationType.OneToOne, "OrganisationalObject_", false);







                    relation.AddEntityFieldPair(OrganisationalObjectFields.OrganisationalObjectId, OrganisationalUnitFields.OrganisationalUnitId);



                    relation.InheritanceInfoPkSideEntity = InheritanceInfoProviderSingleton.GetInstance().GetInheritanceInfo("OrganisationalObjectEntity", false);

                    relation.InheritanceInfoFkSideEntity = InheritanceInfoProviderSingleton.GetInstance().GetInheritanceInfo("OrganisationalUnitEntity", true);

                    return relation;

              }

        }

We have tried (Designer setting/Project Properties):

FieldMappedOnOneManyToOnePattern -> {$EndEntityName$S}Using{$StartEntityFieldNames}To{$EndEntityFieldNames}

FieldMappedOnOneToManyPattern -> {$EndEntityName$P}Using{$StartEntityFieldNames}To{$EndEntityFieldNames}

This alters the property names in individual entities as expected but has no effect on the names of the two associated relations.

Kind regards, O!nK!

OrganisationalUnit is an OrganisationalObject (1:1) using PK to PK.

That's a Target per entity inheritance hierarchy, right?

Hi Walaa,

No it is not. We do not wish to use inheritance (supertype/subtype) in that particular situation.

Thanks for the quick response.

Would you please post the DDL SQl of both tables?

Hi,

Here it is...

/****** Object: Table [dbo].[tOrganisationalUnit] Script Date: 09/09/2008 17:19:44 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[tOrganisationalUnit]( [OrganisationalUnitId] [uniqueidentifier] NOT NULL DEFAULT (newsequentialid()), [ParentOrganisationalUnitId] [uniqueidentifier] NULL, [isInheritingPermissions] [bit] NULL DEFAULT ((1)), [sendSystemMessagesViaEmail] [bit] NULL DEFAULT ((1)), [sendPerformanceNotifications] [bit] NULL DEFAULT ((1)), [isReserved] [bit] NOT NULL DEFAULT ((0)), [isRecycled] [bit] NULL DEFAULT ((0)), [isActive] [bit] NULL DEFAULT ((1)), [Metric] [decimal](18, 3) NOT NULL DEFAULT ((50)), [LastModified] [datetime] NOT NULL DEFAULT (getdate()), [LastModifiedUserId] [uniqueidentifier] NOT NULL, CONSTRAINT [PK_tOrganisationalUnit] PRIMARY KEY CLUSTERED ( [OrganisationalUnitId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

GO ALTER TABLE [dbo].[tOrganisationalUnit] WITH CHECK ADD CONSTRAINT [FK_tOrganisationalUnit_tOrganisationalObject] FOREIGN KEY([OrganisationalUnitId]) REFERENCES [dbo].[tOrganisationalObject] ([OrganisationalObjectId]) GO ALTER TABLE [dbo].[tOrganisationalUnit] CHECK CONSTRAINT [FK_tOrganisationalUnit_tOrganisationalObject] GO ALTER TABLE [dbo].[tOrganisationalUnit] WITH CHECK ADD CONSTRAINT [FK_tOrganisationalUnit_tOrganisationalUnit] FOREIGN KEY([ParentOrganisationalUnitId]) REFERENCES [dbo].[tOrganisationalUnit] ([OrganisationalUnitId]) GO ALTER TABLE [dbo].[tOrganisationalUnit] CHECK CONSTRAINT [FK_tOrganisationalUnit_tOrganisationalUnit]

and...

/****** Object: Table [dbo].[tOrganisationalObject] Script Date: 09/09/2008 17:20:30 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[tOrganisationalObject]( [OrganisationalObjectId] [uniqueidentifier] NOT NULL CONSTRAINT [DF__tOrganisa__Organ__6754599E] DEFAULT (newsequentialid()), [OrganisationalObjectTypeId] [uniqueidentifier] NOT NULL, [OrganisationalUnitId] [uniqueidentifier] NULL, [ManagedByUserId] [uniqueidentifier] NULL, [isReserved] [bit] NULL CONSTRAINT [DF__tOrganisa__isRes__68487DD7] DEFAULT ((0)), [isRecycled] [bit] NULL CONSTRAINT [DF__tOrganisa__isRec__693CA210] DEFAULT ((0)), [isActive] [bit] NULL CONSTRAINT [DF__tOrganisa__isAct__6A30C649] DEFAULT ((1)), [Metric] [decimal](18, 3) NOT NULL CONSTRAINT [DF__tOrganisa__Metri__6B24EA82] DEFAULT ((50)), [LastModified] [datetime] NOT NULL CONSTRAINT [DF__tOrganisa__LastM__6C190EBB] DEFAULT (getdate()), [LastModifiedUserId] [uniqueidentifier] NOT NULL, CONSTRAINT [PK_tOrganisationalObject] PRIMARY KEY CLUSTERED ( [OrganisationalObjectId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

GO ALTER TABLE [dbo].[tOrganisationalObject] WITH CHECK ADD CONSTRAINT [FK_tOrganisationalObject_tOrganisationalObjectType] FOREIGN KEY([OrganisationalObjectTypeId]) REFERENCES [dbo].[tOrganisationalObjectType] ([OrganisationalObjectTypeId]) GO ALTER TABLE [dbo].[tOrganisationalObject] CHECK CONSTRAINT [FK_tOrganisationalObject_tOrganisationalObjectType] GO ALTER TABLE [dbo].[tOrganisationalObject] WITH CHECK ADD CONSTRAINT [FK_tOrganisationalObject_tOrganisationalUnit1] FOREIGN KEY([OrganisationalUnitId]) REFERENCES [dbo].[tOrganisationalUnit] ([OrganisationalUnitId]) GO ALTER TABLE [dbo].[tOrganisationalObject] CHECK CONSTRAINT [FK_tOrganisationalObject_tOrganisationalUnit1] GO ALTER TABLE [dbo].[tOrganisationalObject] WITH CHECK ADD CONSTRAINT [FK_tOrganisationalObject_tSystemObject] FOREIGN KEY([OrganisationalObjectId]) REFERENCES [dbo].[tSystemObject] ([SystemObjectId]) GO ALTER TABLE [dbo].[tOrganisationalObject] CHECK CONSTRAINT [FK_tOrganisationalObject_tSystemObject]

Thanks.

Reproduced. We'll get back to you on this.

It's a bit problematic: it chooses a PK field to be sure the names are unique. Normally this situation won't happen, though in edge cases like your model it will.

The workaround is to rename the PK on the FK side, i.e. OrganisationalUnit, to Id. I know this is a restriction and not what you want, but the alternatives aren't really great either: always emitting pk+fk field names in the names isn't great as often they're equal and it makes names REALLY long sometimes. Picking the PK field name can't be done as one could have multiple 1:1 relations with the same entity which could cause problems as well.

Changing this is also a breaking change so we can't change it now.

Thanks Otis,

That resolved it...

In the 2 relationships that exist between the 2 tables, the 'FK' of each relationship has the same name, even though the fields are in different tables, causing problems for the entity generator...

We have however opted to rather change the name of the FK field in the OO table to 'OrganisationalUnitFKId', which correctly results in the 2 unique relation property names...

Thank you very much for you and your team's quick response.

BTW: I loved the Hague, I lived there for over 4 years while working for Dutchtone (now Orange). I miss my 'kroketten' and 'haring' diet and those awesome Beach cabana bars that they bring out in Scheveningen when it's summertime

Cheers!