coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Ya'll are correct. Mayhap we'll call them hashes. Or HUIDs. That way we know what we're talkin' about. :D

From: Eric Schultz [mailto:wwahammy@xxxxxxxxx]
Sent: Thursday, August 12, 2010 5:39 PM
To: Trevor Dennis
Cc: Garrett Serack; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Questions, Questions, Questions

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