Too late, it's not my data model, it's being fed to me by a vendor. The primary key is a transaction id, and the linking field is a specific primary key, so that there's a parent child relationship. They don't tell you it's a key, and maybe it's not their key, but we get the data from them and we store it locally, In over 10 million records at this point that transaction key is unique among all records. We could generate our own primary key and keep it hidden, but really that only makes more work for us in trying to tie the records together.
Good fun... Tony On Wed, Mar 16, 2022 at 1:06 PM Lon Varscsak <lon.varsc...@gmail.com> wrote: > 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 > > >> > > >
