IDs for Interfaces

[Chris Geer <ch...@cxtsoftware.com>]

As we move to this interface model one thing we are now missing is a common
way of handling unique IDs. The JPA models have the EntityID
which uniquely identifies a JPA object but those aren't included in the
interface. That being said, we probably need to put a unique ID in the
interface so that you can identify the objects without having to know what
backend they came from. It doesn't have to map directly to the backend id.
but needs to be unique. I did notice that a couple of the objects include
get/setId methods which are Longs. We could standardize on that or consider
something like a GUID since they are easy to generate uniquely. I would
also suggest the interfaces should only have getter methods for the ID
since it seems awkward to change somethings unique ID since that could have
massive impacts. This might be something we wait for until the second round
of refactoring but I was thinking about it as I was working.

This also leads into a conversation about the interface model as a whole
and will it always be a "deep" model like JPA (where everything is object
relationships and the whole model is loaded all the time) or do we need to
allow for a "shallow" model where some objects contain the IDs of their
relationships and not the objects themselves? Food for thought as we
continue to talk about the modularization topic.

Chris

RE: IDs for Interfaces

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: Chris Geer [mailto:chris@cxtsoftware.com]
>Sent: Saturday, June 02, 2012 6:57 PM
>To: dev
>Subject: IDs for Interfaces
>
>As we move to this interface model one thing we are now missing is a
>common
>way of handling unique IDs. The JPA models have the EntityID
>which uniquely identifies a JPA object but those aren't included in the
>interface. That being said, we probably need to put a unique ID in the
>interface so that you can identify the objects without having to know what
>backend they came from. It doesn't have to map directly to the backend id.

+1

>but needs to be unique. I did notice that a couple of the objects include
>get/setId methods which are Longs. We could standardize on that or consider
>something like a GUID since they are easy to generate uniquely. I would
>also suggest the interfaces should only have getter methods for the ID
>since it seems awkward to change somethings unique ID since that could have
>massive impacts. This might be something we wait for until the second round
>of refactoring but I was thinking about it as I was working.
>

At the moment, I think we should try to make the least amount of changes.  Once we have everything working correctly, I think we should definitely revisit how we handle IDs.

>This also leads into a conversation about the interface model as a whole
>and will it always be a "deep" model like JPA (where everything is object
>relationships and the whole model is loaded all the time) or do we need to
>allow for a "shallow" model where some objects contain the IDs of their
>relationships and not the objects themselves? Food for thought as we
>continue to talk about the modularization topic.

In addition to this discussion, I think we should re-evaluate the object model as a whole, much as the pages proposal in the wiki is spearheading.  I could definitely see another proposal under Persistence for simplifying the model to whatever degree is possible. With the model no longer directly coupled to the table structure, we have a *bit* more freedom than before.  

>
>Chris