Skip site navigation (1) Skip section navigation (2)

Re: Question about fk and uk for Database Modeler

From: Luis Ochoa <ziul1979(at)gmail(dot)com>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Question about fk and uk for Database Modeler
Date: 2011-05-22 21:02:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Sun, May 22, 2011 at 2:10 AM, Guillaume Lelarge

> On 05/20/2011 05:26 PM, Luis Ochoa wrote:
> > I'm checking right now database designer way of updating / creating
> foreign
> > keys from pk, and as part of this work I want to add uk / fk
> implementation,
> > but I want to check some points before, because I'm not totally sure
> about
> > it, please I'll appreciate your help.
> >
> > 1.How should I add option to choose between pk and uk as source of
> foreign
> > key ?
> > my idea: right click over relationship let me choose source of fk:  uk
> > (allow me to choose which uk of many) or pk
> >
> Fine to me.

Implemented yet.

> > 2. When I create a fk some columns are added to table
> Why? a user could create a FK with existing columns.

Right, thanks for point me that, because I focused on programming and not at
usability :(  but right now is implemented in this way:

- User created a relationship between tables, by default of pk kind, but
dependents of kind a fk column is added to destination table for each pk/uk
column from source table with name tablesourcename_column.

Next user is (or will be) able to:
- After fk columns are added he can change name for whatever he likes.
(implemented soon)
- Only If user select to use auto generate names, a change at table source
column name automagically change destination fk name to adjust it. User will
be able to select for each column what he likes auto generated name or
customized (sync is implemented yet, but selection of user for customized or
auto generated name will be implemented soon).

- Now after your question, I notice that a user is able to use an existing
column as fk, and then I will create a fk->column mapping dialog for this
goal, that allow user to choose which existing column is binded to which fk.
(implemented soon)


> > and MATCH matchtype right
> > now is only MATCH FULL but I have more options to choose like: MATCH
> > PARTIAL(is still no implemented yet or docs are outdated )  MATCH
> > SIMPLE, . Question here is should I let the user to choose between match
> > full and simple (not partial yet)?
> Right click on the relationship, and the MATCH FULL/SIMPLE choice is
> available in this contextual menu.

Ok. I'll add this menu item.

> > reference:
> >
> >
> > 3. suppose that I created a fk from a pk if I add hierarchy all fk
> columns
> > become fk/pk that's fine, but if I created a fk from an uk and I add
> > hierarchy, what should be the normal behavior?.
> I don't understand what you mean here.

Ummm my mistake bad question, probably I was sleepy.

This is:  Should I allow to mark as Identifying relationship a foreign key
from an Uk?

> Which TODO are you working on?
I'm working right now with files instead TODO, because I check every file
for every TODO and then implemented, fixed it (with related files) , some
TODOs (minimal as possible) are delayed until now this are Delayed for

1. dditems->figures->ddTableFigure.cpp  //DD-TODO: fix all model to allow
all options from

2. dditems->figures->ddTextColumnFigure.cpp //DD-TODO: Add composite column
functionality by addin subcolumn for composite types, but be careful:
composite types can be recursive (using inside other composite types)

Status Righ now:
- dditems->figures (probably most important TODOs for modeler were here)
TODO are almost done with some related classes and some parts of draw

Regards, Luis.

In response to


pgadmin-hackers by date

Next:From: Luis OchoaDate: 2011-05-22 21:06:48
Subject: Re: A question about database designer first deliverable
Previous:From: Guillaume LelargeDate: 2011-05-22 06:40:26
Subject: Re: Question about fk and uk for Database Modeler

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group