Support for `@Id`less entities [DATAJDBC-470]

[spring-projects-issues]

Lovro Pandžić opened DATAJDBC-470 and commented

In our code we usually name our id columns (and in turn, fields) as id.

With Spring Data JDBC integration domain code then looks like

class Foo {

   @Id
   private Long id;

... other code removed for brevity
}

It seems redundant to define a field named id and then to also annotate it with @Id for Spring DATA JDBC to detect it's semantics.

My proposal is a follows:

Add id field detection to either NamingStrategy or some new abstract construct so I can programmatically link my id naming convention with Spring Data JDBC id field detection mechanism so we can reduce required annotations in code to zero

---

Referenced from: pull request #207

[spring-projects-issues]

Jens Schauder commented

I understand the desire to minimise code, but here I'm not convinced that the added complexity is worth saving three characters per entity. I don't like the idea that a developer has to hunt down some very Spring Data (JDBC) specific implementation just to find out what the primary key of an entity is.

Also if you have a such an established structure for your entities you could encode it in a super class which has the id field (with annotation)

[spring-projects-issues]

Jens Schauder commented

Oliver Drotbohm IF we would support such a feature we should probably support it across modules, shouldn't we? Which means the issue would be correct in Commons

[spring-projects-issues]

Oliver Drotbohm commented

If that's a constraint we'd want to put in place, this is a non starter as we will not be able to make this work for JPA. There is precedence to a default in MongoDB which already defaults properties named id or _id to identifier properties

[spring-projects-issues]

Lovro Pandžić commented

Ok, sorry for not providing more motivation for this case.

It's not only about eliminating annotations, but also about code reuse and eliminating dependencies from domain model to external dependencies.

It's quite common in my organization to share code when connecting different services from different teams. Usually this also mandates code duplication to eliminate "unnecessary" dependencies inside this connector artifact. With this feature shared connector model and persistence layer model could become one as they would literally be the same.

 

[spring-projects-issues]

Lovro Pandžić commented

And to share some more insight why we avoid external dependencies in those connector models - dependency collision

[spring-projects-issues]

Jens Schauder commented

I wasn't aware that something like this exists in SD-MongoDb.
I guess in that case it would even improve consistency

[spring-projects-issues]

Jens Schauder commented

Regarding dependencies: Please note that annotations do not require the presence of the library they come from

[spring-projects-issues]

Thomas Lang commented

Just for everyone`s information:
I am currently working on that issue

[spring-projects-issues]

Jens Schauder commented

After reviewing the PR and polishing it we decided not to do this.

The problem is that it makes only sense to do this for aggregate roots.
But disabling it for inner entities would require some serious effort and would make the whole mapping both conceptually and in code significantly more complex, since now aggregate roots and entities would behaved differently.
And that doesn't make sense for a feature that was intended to make things simpler.

Sorry for wasting the time, but sometimes you only realise something is a bad idea after you see it implemented. 😕

[spring-projects-issues]

Lovro Pandžić commented

Ok, thanks a lot for your time and effort :)
I believe that for my case your comment about annotations not requiring library might be enough