I have natural keys just about everywhere and have only encountered one issue. Exposing the key to the DataObject is fine, but don't expose the same key in a detail object. So if you have OrderHeader.orderNumber that can be exposed, but if that object has a to-many to OrderLines and also has orderNumber in it, do not expose it there (since at this point it's a FK). If you expose it in both you'll potentially have weird problems, especially with parent/child contexts. Other than that, I expose them through the modeler and don't have any issues.
On Thu, Mar 10, 2022 at 8:08 PM Tony Giaccone <t...@giaccone.org> wrote: > Michael, > > Yeah I knew about mapping the attribute, I hadn’t thought about key > generation but clearly that’s a thing. We’re getting a transactionID > that’s unique and we have to prevent duos and ensure that when we get > duplicate copies in the future that we can easily identify if a record has > been updated. To that end I’m calculating a hash on the data fields. That > way I can compare at the hash level and only update the record if the new > entry hash doesn’t match. > > Tony > > > On Mar 10, 2022, at 7:03 PM, Michael Gentry <blackn...@gmail.com> wrote: > > > > Hi Tony, > > > > It has been a while since I've mapped natural primary keys, but Cayenne > > absolutely supports it. > > > > If my memory cells are working, you will map your natural key as a Java > > attribute (in the ObjEntity section). Normally, Cayenne excludes the PK > > from your Java/ObjEntity, but you can manually add it and Cayenne is > happy. > > > > You //might// also need to fiddle with the PK generation section on the > > DbEntity side. For some reason, I'm remembering that specifying Cayenne > > Generated keys works better (or maybe not), even if you aren't generating > > keys. This is only if you are creating new records. Cayenne won't try to > > generate a key for an object that already has a key -- just make sure > your > > new objects have a key before you commit changes. > > > > mrg > > > > > >> On Thu, Mar 10, 2022 at 6:10 PM Tony Giaccone <t...@giaccone.org> > wrote: > >> > >> I'm writing an application where the primary key for a table is a > natural > >> key and comes in as part of a data payload after making a call to a > remote > >> system. I can be certain that this value is unique. So I've modeled it > in > >> the database and have it in the data model. Of course this means that in > >> the java object this field is absent. > >> > >> I'm going to want to do selects on it, and comparisons to other fields. > So > >> I really need it to be part of the model. So is it best to just add it > >> into the java object. So that it's part of the mapping or is there > another > >> technique that is a better choice. > >> > >> Just as an aside, let's not devolve into a discussion of should the key > be > >> visible. I understand the pluses and minuses of that decision and for > this > >> case, its really the right thing to do. > >> > >> > >> > >> Tony Giaccone > >> >
