coapp-developers team mailing list archive

[Eric Schultz <wwahammy@xxxxxxxxx>]

>
> 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.


I think you bring up a good point Trevor. I'm a bit of a stickler on the
wording myself. The main reason we used the word GUID is that MSI has a
column format for GUIDs. Maybe we could use a different word or phrase like
'hashed GUID' or 'HUID'? It would imply it looks and acts like a GUID but it
can't be created using GUID functions.

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.


That suggestion sounds fine with me. I don't see a reason to use prefixed
columns unless someone else does.

Eric

On Thu, Aug 12, 2010 at 7:18 PM, Trevor Dennis <trevor@xxxxxxxxxxxxx> wrote:

> 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
>