Entity
class. This is not mandatory, but is considered as a good practice. Entity
class usually contains implementation of hashCode()
and equals()
methods, based on the primary key of the class. Again, this is also not mandatory and some would consider the whole instance state then just primary keys. This is fine; using just primary keys is somewhat more pragmatic - and faster - if code is written with having that in mind.Telecom
s.Telecom
, fetch list of its TelecomPrefix
Telecom
, fetch the belonging Country
.TelecomPrefix
es inside of Telecom
, as well as the single Country
. Therefore, we can write something like this:TelecomPrefix
es, we could use any Collection
. {: .attn}TelecomPrefix
entities for some Telecom
he would need to manually convert it to an array and set it to target.Country
instance into the Telecom
instance, in the single row. Here is how to do so:TelecomPrefix
into the Telecom.prefixes
property, as well to inject Country
into the Telecom.country
! Resulting list elements would have just one element, a Telecom
, since all other mapped elements are injected into this instance.Country
; there is a failure with one-to-many relationships, like with TelecomPrefix
. This is because for the each row of result set, DbOom will create a new instance of Telecome
. Hence, if a telecom contain two prefixes, it will be listed twice and each time telecom will link just one, different, telecom prefix!Telecom
for each its prefix, there will be just one instance, with many prefixes injected into it.Set
instead of List
\:Set
is not always an option. Can we have a List
, but without duplicate entries? Sure! DbOomQuery
supports so called "entity mode". It goes one step further from cacheEntities
, so enabling the entity mode will also enable cached entities.List
without the duplicates! Just a nice object tree, ready to be used :)