Ännu mer dao-fwk funderingar

[Niklas Gustavsson]

Tja,

finns tydligen oändliga diskussionsämnen kring dao-fwk :-)

Vet att vi diskuterat detta tidigare, men fick vi detta helt rätt?
se.vgregion.dao.domain.patterns.repository.db.jpa.AbstractJpaRepository.find(ID)

Denna borde väl vara abstrakt och krävas att man implementerar i sitt
repository? (eller att man väljer att subklassa DefaultJpaRepository
och tar hela grejen med att PK==ID)

/niklas

[Anders Asplund]

> finns tydligen oändliga diskussionsämnen kring dao-fwk :-)

Stora ämnen skapar stora debatter :)

> Denna borde väl vara abstrakt och krävas att man implementerar i sitt
> repository?

Jag missar säkert något uppenbart... men varför?

[Niklas Gustavsson]

2010/11/25 Anders Asplund <aasp...@gmail.com>:

>> Denna borde väl vara abstrakt och krävas att man implementerar i sitt
>> repository?
> Jag missar säkert något uppenbart... men varför?

find() bör väl söka på ID, men nuvarande implementation söker baserat
på PK och jag ser inte hur vi skulle kunna göra en rimlig
implementation som vet hur den skulle söka. Här är ett exempel på en
find jag implementerat:

public Feed find(String id) {
try {
return (Feed) entityManager.createQuery("select l from
DefaultFeed l where l.feedId = :id")
.setParameter("id", id)
.getSingleResult();
} catch(NoResultException e) {
return null;
}
}

I andra fall har jag mer komplicerade identiteter, och då blir
implementationen därefter.

/niklas

[Niklas Gustavsson]

2010/11/25 Niklas Gustavsson <niklas.g...@callistaenterprise.se>:

> Denna borde väl vara abstrakt och krävas att man implementerar i sitt
> repository? (eller att man väljer att subklassa DefaultJpaRepository
> och tar hela grejen med att PK==ID)

Vi har en relaterad problematik i store() där vi gör följande:
entityManager.find(type, entity.getId())

Givet att PK inte nödvändigtvis är det samma som ID, så är ju detta
lite problematiskt.

/niklas

[Anders Asplund]

> find() bör väl söka på ID, men nuvarande implementation söker baserat
> på PK och jag ser inte hur vi skulle kunna göra en rimlig
> implementation som vet hur den skulle söka. Här är ett exempel på en
> find jag implementerat:
>
> public Feed find(String id) {
> try {
> return (Feed) entityManager.createQuery("select l from
> DefaultFeed l where l.feedId = :id")
> .setParameter("id", id)
> .getSingleResult();
> } catch(NoResultException e) {
> return null;
> }
> }

"I get your point". Är lite osäker på hur JPA funkar här men är det så att entitymanager hanterar en entitets unikitet utifrån hashcode medans den använder PK(@ID) när den skall hämta från db? Tanken har slagit mig innan och dyker upp nu igen: Är det för drastiskt låta entitets id bli PK i fallet av en JPA-implementation? Mao ta bort PK och sätta @Id på ID istället?

Annars bra synpunkt som jag köper!

//Anders

[Anders Asplund]

> Vi har en relaterad problematik i store() där vi gör följande:
> entityManager.find(type, entity.getId())

Med en patchad find är det ju inga problem att fixa detta heller...

[Niklas Gustavsson]

2010/11/25 Anders Asplund <aasp...@gmail.com>:

> "I get your point". Är lite osäker på hur JPA funkar här men är det så att entitymanager hanterar en entitets unikitet utifrån hashcode medans den använder PK(@ID) när den skall hämta från db?

Jepp, i alla fall Hibernate (om du säger hashcode/equals).

> Tanken har slagit mig innan och dyker upp nu igen: Är det för drastiskt låta entitets id bli PK i fallet av en JPA-implementation? Mao ta bort PK och sätta @Id på ID istället?

Det är säker ett val i många fall, men tveksam om det alltid är det
bästa alternativet.

/nikas

[Niklas Gustavsson]

2010/11/25 Niklas Gustavsson <niklas.g...@callistaenterprise.se>:

> Denna borde väl vara abstrakt och krävas att man implementerar i sitt
> repository? (eller att man väljer att subklassa DefaultJpaRepository
> och tar hela grejen med att PK==ID)

Jag har committat detta i rev 72, issue 3.

/niklas