DEV Community: Sanjay Kumar A

I Used the Wrong @Id Import in Spring Boot and MongoDB. It Worked Anyway

Sanjay Kumar A — Fri, 28 Aug 2026 13:38:47 +0000

Last week I wrote a post about moving my Spring Boot project from MySQL to MongoDB. Somewhere in the middle of it I wrote a warning that sounded very confident.

I said: if you import @Id from jakarta.persistence instead of the Spring Data one, your ID mapping breaks and findById() stops working.

Then I went back and actually tried it.

It worked. Everything saved, everything loaded, nothing complained.

So I had to sit down and figure out why my broken code was not broken. What I found is more useful than the warning I gave, so here it is.

The two @id annotations

Java has this annoying situation where two completely different libraries give you an annotation with the same name:

import jakarta.persistence.Id;                    // this is the JPA one
import org.springframework.data.annotation.Id;    // this is the Spring Data one

In your class both look the same:

@Id
private String id;

You cannot tell which one you used by looking at it. Only the import line tells you. And your IDE will pick one for you when you press the auto-import shortcut, usually whichever it saw first.

Here is my Task class:

@Document(collection = "app_tasks")
public class Task {

    @Id
    private String id;

    private String title;
    private String status = "PENDING";
}

I had the wrong import here for a while. I never noticed, because nothing went wrong.

Why nothing went wrong

Spring Data MongoDB has a backup plan I did not know about.

A field becomes the _id in MongoDB if either of these is true:

It has @Id from org.springframework.data.annotation
It has no recognised annotation, but the field is named id Look at rule 2 again. That is what saved me.

Spring Data saw my JPA @Id and did not recognise it. Not its annotation, so it ignored it. But then it looked at my field name, saw id, and mapped it to _id anyway.

My wrong import did nothing at all. The field name did all the work.

When it does break

The backup plan only works if the field is called id. Change the name and it is gone.

@Document(collection = "app_tasks")
public class Task {

    @Id                       // still the wrong import
    private String taskId;    // and now not called "id"

    private String title;
}

Now neither rule applies. The annotation is not recognised and taskId is just a normal name. So Spring Data treats taskId as a regular field, and MongoDB creates its own separate _id that your Java object never sees.

And here is the bad part: nothing tells you.

No error. No warning. The app starts fine, saves work fine. But:

taskId comes back null on every record you read
findById() returns empty for records you can clearly see in the database
Every document has a hidden _id your code cannot touch You only find out when you try to fetch one specific record and it is not there. Then you spend an evening thinking your query is wrong, when the problem was an import line you wrote weeks ago.

Check your project right now

Open your model class. Look at the import, not the annotation.

import org.springframework.data.annotation.Id;   // correct for MongoDB
import jakarta.persistence.Id;                   // wrong here

If yours says jakarta.persistence, change it. Even if your app works today, it is only working because of the field name.

Second check. Save one record, then look at it in MongoDB Compass or the shell:

db.app_tasks.findOne()

If you see an _id and a separate taskId sitting next to each other, your mapping is broken. When it is correct, there is only _id.

A way to avoid the whole problem

If you want to stop worrying about which @Id you imported, Spring Data MongoDB has its own annotation:

import org.springframework.data.mongodb.core.mapping.MongoId;

@MongoId
private String taskId;

@MongoId only exists in the MongoDB module. There is no JPA version, so your IDE cannot import the wrong one. Nice option if your project touches both JPA and MongoDB.

What I actually took from this

The bug I warned everyone about was not the real bug. The real problem was simpler: I did not know why my own code worked.

My import was wrong. My project ran fine. I would have carried that mistake into every future project and never known, until the day I renamed a field and lost an evening to it.

Code running is not the same as code being right. I keep learning this one.

Short version:

Spring Data MongoDB maps _id from the @Id annotation, or from a field just being named id
The name rule hides a wrong import, so the wrong one often looks fine
Rename the field and it breaks quietly — no error, just empty results
Check the import line, not the annotation
@MongoId avoids the whole mess Has this happened to you? Code that worked, but not for the reason you thought? I would like to hear it.

From MySQL to MongoDB in Spring Boot — Everything That Changed in My Code

Sanjay Kumar A — Wed, 19 Aug 2026 09:20:24 +0000

In my last post I wrote about an error that cost me a full evening: my pom.xml had the MongoDB starter, but my code was still full of JPA annotations. The compiler kept saying cannot find symbol: class Entity.

That post was about the error. This post is about the fix — every single line I had to change to move my Task Manager project from MySQL to MongoDB.

If you are planning the same switch, this is the checklist I wish I had.

1. The dependency

Before (MySQL + JPA):

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

After (MongoDB):

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>

One starter replaces two dependencies. And this is exactly where my problem started — I added the new one but never removed the old one, so half my code still compiled and half did not.

Remove the JPA starter completely. If you leave it in, the jakarta.persistence annotations still resolve, and you will not notice you are mixing two worlds until something breaks at runtime.

2. application.properties

Before:

spring.datasource.url=jdbc:mysql://localhost:3306/taskmanager
spring.datasource.username=root
spring.datasource.password=yourpassword
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

After:

spring.data.mongodb.uri=mongodb://localhost:27017/taskmanager

Five lines became one.

No ddl-auto because MongoDB has no schema to create. No dialect because there is no SQL being generated. The database and the collection are created automatically the first time you insert a document.

3. The model class

This is where most of the work was. Here is my actual Task class after the migration:

package com.taskmanager.task_manager;

import com.fasterxml.jackson.annotation.JsonIgnore;
import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.mapping.DBRef;
import org.springframework.data.mongodb.core.mapping.Document;

@Document(collection = "app_tasks")
public class Task {

    @Id
    private String id;

    private String title;
    private String description;
    private String status = "PENDING";

    @DBRef
    @JsonIgnore
    private User user;

    public String getId() { return id; }
    public String getTitle() { return title; }
    public void setTitle(String title) { this.title = title; }
    public String getDescription() { return description; }
    public void setDescription(String desc) { this.description = desc; }
    public String getStatus() { return status; }
    public void setStatus(String status) { this.status = status; }
    public User getUser() { return user; }
    public void setUser(User user) { this.user = user; }
}

Compare that with the JPA version it replaced:

@Entity
@Table(name = "app_tasks")
public class Task {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;
    private String description;
    private String status = "PENDING";

    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;

    // getters and setters
}

The changes, one by one:

JPA	MongoDB
`@Entity`	`@Document(collection = "app_tasks")`
`@Table(name = "...")`	folded into `@Document`
`@Id` from `jakarta.persistence`	`@Id` from `org.springframework.data.annotation`
`@GeneratedValue`	not needed
`Long id`	`String id`
`@ManyToOne` + `@JoinColumn`	`@DBRef`

The import trap

@Id exists in both worlds. The annotation name is identical, so your IDE will happily auto-import the wrong one and nothing will look wrong in the editor.

If you import jakarta.persistence.Id in a MongoDB project, Spring Data does not recognise it as the document ID. Your documents get saved with a generated _id that your Java field never sees, and findById() starts returning empty for records you know exist.

Check the import line. Not the annotation.

Why the ID became a String

MongoDB generates an ObjectId — a 24-character hex value like 66b3f1c2a4e5d67890abcd12. It does not fit in a Long.

You can map it to a String and let Spring Data convert it, which is what I did. That one change then ripples through your whole project, which brings me to the part that actually broke things.

4. The repository

Before:

public interface TaskRepository extends JpaRepository<Task, Long> {
    List<Task> findByStatus(String status);
}

After:

public interface TaskRepository extends MongoRepository<Task, String> {
    List<Task> findByStatus(String status);
}

Two changes: the interface name and the ID type. The derived query method findByStatus works exactly the same — Spring Data reads the method name and builds a Mongo query instead of SQL.

This was the nicest surprise of the migration. If your repository only uses derived query methods, it migrates almost for free.

5. What actually broke

The model and repository were easy. These were not.

Every ID in the controller

Long id became String id in the entity, so every method signature that touched an ID had to change too:

// Before
@GetMapping("/{id}")
public Task getTask(@PathVariable Long id) { ... }

// After
@GetMapping("/{id}")
public Task getTask(@PathVariable String id) { ... }

The compiler catches most of these. What it does not catch is any place you were doing arithmetic or comparison on the ID, or parsing it with Long.parseLong(). Search your project for parseLong before you assume you are done.

`@DBRef` is not a join

I replaced @ManyToOne with @DBRef, and it does store a reference to the User document. But it is not a SQL join.

MongoDB fetches the referenced document with a second query. Load 50 tasks with @DBRef users and you get 51 database round trips. In SQL, one join would have done it.

For a student project with a small dataset this is fine. If your data is going to grow, the MongoDB way is to embed the fields you actually need — for example, storing just userId and username directly on the task — instead of referencing a whole document.

I kept @DBRef because my task list is per-user and never loads more than a handful at a time. Know that you are making that trade, though.

Native queries

Anything written as @Query(value = "SELECT * FROM ...", nativeQuery = true) is gone. There is no SQL to run. You rewrite those either as derived method names or as MongoDB's own query syntax:

@Query("{ 'status': ?0 }")
List<Task> findByStatusCustom(String status);

Same annotation name, completely different language inside it.

Transactions

@Transactional across multiple saves does not behave the way you expect out of the box. MongoDB supports multi-document transactions, but only on a replica set — a plain standalone local install will not give them to you.

I did not need them, so I moved on. Just do not assume the annotation is doing what it did before.

6. What I would do differently

Pick the database before writing the entity classes.

That sounds obvious. But what actually happened was: I followed a JPA tutorial, wrote my model, then read that MongoDB was "easier for flexible data" and swapped the dependency without touching anything else. The mismatch between my pom.xml and my code is what generated that cannot find symbol error in the first place.

The second thing: do not migrate a database because it sounds better. Ask what your data actually looks like. My tasks have a fixed set of fields and a clear relationship to a user — honestly, that is relational data, and MySQL was a reasonable fit for it.

I stayed on MongoDB because I wanted to learn it and because the flexible schema helps while I am still changing fields every week. That is a real reason. "It's more modern" is not.

The short checklist

Remove the JPA starter and the SQL driver. Completely.
Add spring-boot-starter-data-mongodb.
Replace the datasource properties with spring.data.mongodb.uri.
@Entity → @Document, and check the @Id import.
Long id → String id, then fix every controller signature.
JpaRepository<T, Long> → MongoRepository<T, String>.
Rewrite native SQL queries.
Decide whether references or embedding fits your data.

If you have made this switch, I want to know one thing: did you go with @DBRef or did you embed? I am still not sure I picked right.

Cannot find symbol: class Entity — My pom.xml Said MongoDB, My Code Said MySQL

Sanjay Kumar A — Sun, 09 Aug 2026 10:45:04 +0000

I opened an old Spring Boot project of mine and ran a build. It failed with 20 compilation errors.

Every error said the same kind of thing: some class does not exist. @Entity does not exist. JpaRepository does not exist. My first thought was that something was wrong with my Java setup.

It wasn't. The real cause was one line in pom.xml, and it took me a while to find it.

The error

[ERROR] package org.springframework.data.jpa.repository does not exist
[ERROR] package jakarta.persistence does not exist
[ERROR] cannot find symbol: class JpaRepository
[ERROR] cannot find symbol: class Entity
[ERROR] cannot find symbol: class Table
[ERROR] cannot find symbol: class ManyToOne
[INFO] 20 errors

The cause

@Entity, @Table and @Column come from JPA, which is for SQL databases. Those classes live in the spring-boot-starter-data-jpadependency. My project did not have it — it had spring-boot-starter-data-mongodb instead. So the compiler was right. Those classes were never in my project.

import jakarta.persistence.*;

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(unique = true, nullable = false)
    private String username;
}

And this is what was in my pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>

The fix

JPA (SQL)	MongoDB
`@Entity` + `@Table`	`@Document`
`jakarta.persistence.Id`	`org.springframework.data.annotation.Id`
`@GeneratedValue`	delete it
`@Column`	delete it
`@Column(unique = true)`	`@Indexed(unique = true)`
`@ManyToOne` + `@JoinColumn`	`@DBRef`
`JpaRepository<T, Long>`	`MongoRepository<T, String>`
`Long id`	`String id`

User.java after the change:

package com.taskmanager.task_manager;

import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.index.Indexed;
import org.springframework.data.mongodb.core.mapping.Document;

@Document(collection = "app_users")
public class User {

    @Id
    private String id;

    @Indexed(unique = true)
    private String username;

    private String password;

    private String role = "USER";
}

What broke next

The build went from 20 errors to 3:

[ERROR] TaskService.java:[39,45] incompatible types: java.lang.Long cannot be converted to java.lang.String
[ERROR] TaskService.java:[52,45] incompatible types: java.lang.Long cannot be converted to java.lang.String
[ERROR] TaskService.java:[59,35] incompatible types: java.lang.Long cannot be converted to java.lang.String

MongoDB ids are String, not Long. So every method that took an id had to change:

public Task updateStatus(String id, String status, String username)
public void deleteTask(String id, String username)

Then the controller broke too:

@PathVariable Long id      // before
@PathVariable String id    // after

The runtime error

The build passed. The app still would not start:

Caused by: com.mongodb.DuplicateKeyException: Write failed with error code 11000
and error message 'Index build failed: E11000 duplicate key error collection:
test.users index: username dup key: { username: null }'

Old documents in that collection had no username field, which MongoDB stores as null. A unique index cannot be built when two documents both have null.

My fix was to use fresh collections:

@Document(collection = "app_users")   // was "users"
@Document(collection = "app_tasks")   // was "tasks"

The app started after that.

Proof it works

$r = Invoke-RestMethod -Uri http://localhost:8080/auth/login -Method Post -ContentType "application/json" -Body '{"username":"sanjay","password":"test123"}'
$h = @{ Authorization = "Bearer " + $r.token }
Invoke-RestMethod -Uri http://localhost:8080/tasks -Method Get -Headers $h

content       : {@{description=About the MongoDB JPA mismatch;
                id=6a77526eb624bcbc15259596; status=PENDING;
                title=Write my first Dev.to article}}
totalElements : 1
totalPages    : 1

What I would tell myself

When the compiler says a Spring class does not exist, check pom.xml before checking your own code.
Your config and your code must agree on the database. Mine disagreed for months because I never ran the project.
Changing the id type is not a 4-file change. Search for Long id across the whole project first.
E11000 ... dup key: { username: null } is about old data, not your new annotations.
Always put the database name in your Mongo connection string. Without it you are writing to a database called test.
A build that compiles is not a working app. Run the endpoints.

Code: github.com/sanjayfreak/Smart-Task-Manager