Composite Keys? (plus feature request)

[Wolfgang Keller]

Hello,

is there any chance to be able to use Sqlkit with database schemas that
use composite keys anytime soon?

I do like a L-O-T the idea of a generic CRUD application that can
automatically re-engineer any database schema. One thing that would be
extremely useful is, for databases that follow a structured*
entity-relationship schema, to display the dependency tree of all
database tables in a tree list view.

TIA,

Sincerely,

Wolfgang

*this essentially means that the dependency graph of the tables does
not include any directed cycles (hen-egg-type-relationships).

--
Führungskräfte leisten keine Arbeit (D'Alembert)

[Alessandro Dentella]

On Sat, Oct 08, 2011 at 09:20:07PM +0200, Wolfgang Keller wrote:
> Hello,
>
> is there any chance to be able to use Sqlkit with database schemas that
> use composite keys anytime soon?

Well, this is already working. Is been this way since the beginning. What is
not working is a composite FK, but that's just for completion purpose.

> I do like a L-O-T the idea of a generic CRUD application that can
> automatically re-engineer any database schema. One thing that would be
> extremely useful is, for databases that follow a structured*
> entity-relationship schema, to display the dependency tree of all
> database tables in a tree list view.

that's interesting, but it's not something I see directly connected to
sqlkit. At least it'd be a nice plugin but more on the side of the
administration of a database, than on it's use.

sandro
*:-)

--
Sandro Dentella *:-)
http://www.reteisi.org Soluzioni libere per le scuole
http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

[Wolfgang Keller]

> Well, this is already working. Is been this way since the beginning.
> What is not working is a composite FK, but that's just for completion
> purpose.

???

I don't see why there would (could!) be any distinction between primary
and foreign keys. If a database uses composite primary keys, it also
HAS TO use composite foreign keys, obviously, because the foreign key
HAS TO BE the same as the primary key of the other table. By
definition how foreign keys work.

> > I do like a L-O-T the idea of a generic CRUD application that can
> > automatically re-engineer any database schema. One thing that would
> > be extremely useful is, for databases that follow a structured*
> > entity-relationship schema, to display the dependency tree of all
> > database tables in a tree list view.
>
> that's interesting, but it's not something I see directly connected to
> sqlkit. At least it'd be a nice plugin but more on the side of the
> administration of a database, than on it's use.

???

I am coming from the end-user side, and the dependency tree of all
entities is exactly what I would want to see as THE primary GUI
element for ANY database application.

In fact for me, a "generic" CRUD application would only require three
different GUI elements:
- the dependency tree of all tables (since all sane databases would
use a strict SER schema)
- grids for each table
- forms, each of which which can "span" several tables

Sincerely,

Wolfgang

[Alessandro Dentella]

On Tue, Oct 11, 2011 at 01:10:45PM +0200, Wolfgang Keller wrote:
> > Well, this is already working. Is been this way since the beginning.
> > What is not working is a composite FK, but that's just for completion
> > purpose.
>
> ???
>
> I don't see why there would (could!) be any distinction between primary
> and foreign keys. If a database uses composite primary keys, it also
> HAS TO use composite foreign keys, obviously, because the foreign key
> HAS TO BE the same as the primary key of the other table. By
> definition how foreign keys work.

Agreed.

I'm just stating that sqlkit *completion* feature , (i.e. the fact that it
can suggest possible values getting them from the referenced table, using
search-field, and format field as explained here [1]) won't work with
composite fk, that doesn't mean you can't *edit* tables with composite
foreign keys, just that you can't relay on correct completion.

The reason I haven't implemented is that I have many tables with single
primary key and just some tables with composite primary key (mainly tables
used in m2m relations).

I didnt' really need completion on that tables. I'd be more than happy to
accept a patch that fixes this missing capability, though.

I'm not even stating this would be really difficult to add. In my wish list
anyhow association proxies (SQLA items) come first as I need them much more.

>
> > > I do like a L-O-T the idea of a generic CRUD application that can
> > > automatically re-engineer any database schema. One thing that would
> > > be extremely useful is, for databases that follow a structured*
> > > entity-relationship schema, to display the dependency tree of all
> > > database tables in a tree list view.
> >
> > that's interesting, but it's not something I see directly connected to
> > sqlkit. At least it'd be a nice plugin but more on the side of the
> > administration of a database, than on it's use.
>
> ???
>
> I am coming from the end-user side, and the dependency tree of all
> entities is exactly what I would want to see as THE primary GUI
> element for ANY database application.
>
> In fact for me, a "generic" CRUD application would only require three
> different GUI elements:
> - the dependency tree of all tables (since all sane databases would
> use a strict SER schema)
> - grids for each table
> - forms, each of which which can "span" several tables

Sqlkit has been developed as a package to create database application in a
simple and powerful way, not as a general tool to browse databases. Since it
was pretty easy to add it, I also added the capability to browse database in a
simple way (just a list of tables, possibility to edit them in table format
or form/mask).

The ability to browse a database schema is not one of the core
functionalities, that's what I mean when I say it's a plugin features
(thought there's no such a 'plugin' concept in sqlkit).

sandro
*:-)

[1] http://sqlkit.argolinux.org/sqlkit/completion.html