> > In my case, A owns B, and controls all access to B. So A is > > versioned, there may be duplicate copies of Bs around, for different > > versions of A, and then I pick a point to create a new > > version of A, and close off that version. > > > > so in A I have > > a-pk > > version > > foo > > bar > > > > and in B > > b-pk > > a-fk > > abc > > def > > So if a-pk and b-pk are UUIDs and you create new ones for each new version, how > do you relate one version to another? How do you tell that a-pk1 and a-pk2 are > different versions of the same item? If you had a-pk and version as the compound > PK then you can easily tell that if a-pk is the same for two entities, that they > are different versions of the same entity. > > You could have this instead: > > In A > uuid > a-id > version > foo > bar > > where uuid is the PK, and you have a unique index on (a-id, version) so you can > >use a-id as the common thread between versions.
sorry, missed that. yes, A has a name field, that is the a-id you talk about. > > and a method in A > > > > A newVersion(); > > > > which returns a deep copy of A, but wth a new version. My > > slsb, which controls all access to A, ensures that new versions are > > created as required, and not modified. > > > > how is it sounding? > > > > Good so far, if you can guarantee that all access to the entities goes through > the SLSB. Do you version control B? It looks like no.... hehe ... "if you can guarantee ..." yes... kinda big if there isn't there. someone tell me if I'm missing something int he spec that would allow me to do this? The closest thing I can see is using declaritive security, and having the slsb run-as or something.... yuk... do I version control B? well, yes and no. I dont do anything specific to B, but because each new version of A is a deep copy, I have new Bs for each new version of A. so effectively yes. In reality, B is only an entity bean because we are in early development. ideally it would be one coarse entity rather than two fine grained entities. cheesr dim =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
