coapp-developers team mailing list archive

[Trevor Dennis <trevor@xxxxxxxxxxxxx>]

Hi,

Here's some suggestions from what I've learned from years of database work
and many articles from SQL development forums.


>
> >> In the CO_PACKAGE table, there is an id field. What type is this field
> supposed to be and where does it come from? (autogen by mkPackage, autogen
> by previous part of CoApp toolchain or set by the developer)
>
>
>
>
>
> >> Are CoApp package IDs globally unique? If I say I want package with ID
> 1, I can be safe knowing no other package from any repo will have that ID?
> Are these the IDs you had mentioned should be generated in a consistent
> manner, say with MD5 hashes of name, version, architecture and I assume the
> developer's public key?
>
>
>
> I think ID was intended to be a GUID generated as an MD5 of the {name +
> arch + version + publickeytoken}. Let’s go with that assumption right now.
>
>
>
I don't think we should call this a GUID if you're not using the official
definition of a GUID/UUID from RFC 4122.  If I see GUID in documentation,
I'm going to assume I can call a normal GUID creation function to create
one.

If you're going to create a specific hash for an ID, then refer to it as a
hash.



>
> >> - Do CO_ROLE, CO_TAG and CO_BINDING_POLICY actually get their
> FK_package_id's from CO_PACKAGE_PROPERTIES? That's what the diagram shows
> but it doesn't really make sense to me why that'd be. :)
>
>
>
> The FK_package_id is the foreign key for the package id… which is simply
> the ID field in the CO_PACKAGE table.
>
> FK_role_id is just the ID of the CO_ROLE table.
>
>
>
>
>
It's not good practice to prefix table and columns and tables with things
like 'tbl' or 'fk'.  Save the FK_ for the name of the constraint and not the
name of the column.  If you're trying to relate columns in different tables,
then simply give them a consistent name.  Don't give one table 'ID' and the
second table 'PACKAGE_ID'.  Simply use 'PACKAGE_ID' for both.  Their
relationship becomes obvious.

Also, there is no problem prefixing tables with 'CO' for CoApp since it
provides a semi-namespace.  But, don't prefix all the columns the same way.
 Simply name them for what they are (while avoiding SQL keywords).  I
haven't seen the original message or source though so if you weren't doing
this, then ignore me.



>  Enjoy your Thursday morning :)
>
>
>
> Eric
>
>
>
-- 

Trevor Dennis