rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject RE: IDs for Interfaces
Date Sun, 03 Jun 2012 01:06:01 GMT
>-----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
>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.

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.


View raw message