{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 Rolldiameter 的问题《Many-to-Many Relationship (with properties) in Goo》','https://www.manongdao.com/q-393710.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
I understand from the official documentation on unowned relationships that the app must use sets of Key objects on either side of the relationship. This makes perfect sense.
Coming from many years of RDBM-style programming, though, I'm pretty confused about how I can model properties of that relationship itself. For example, if I have entities Category and Entry in my many-to-many relationship and would like to persist a dateAdded property, or some other data that are only relevant when both sides of the relationship are known.
I suppose it would be possible to create a third class: CategoryEntry that links the two, but this seems like a kludge.
What is the proposed way to model this kind of situation?
A 'relation table' such as you describe, is the standard solution - both in the RDBMS world and in the App Engine datastore - to having a relation with properties. It's not a kludge, because when the relation has attributes other than its existence, it requires somewhere to represent that.