Using Couchbase Enterprise Edition 5.0.0 build 2873 and Spring Data Couchbase 2.1.2, I am getting the error explained at the bottom of the question. Go forward if you just need the short story.
If you want a little more explanation, here it comes:
Imagine that the CrudRepository methods are fine to me. I mean, I don't need to add any more methods.
How the repository would look like? Would I declare an empty repository just like this?
@Repository
public interface PersonRepository extends CrudRepository<Person, String> {
// Empty
}
Or would I use directly CrudRepositoy as my Base repository. I don't think so, because you need to pass Type and ID to the CrudRepository.
But the question is not that. Here comes the question:
How Spring knows how to instantiate PersonRepository, taking into account that there is no implementation of that base repository? Take a look to PersonService and PersonServiceImpl interface/implementation.
Interface:
@Service
public interface PersonService {
Person findOne (String id);
List<Person> findAll();
//...
}
Implementation:
public class PersonServiceImpl implements PersonService {
// This is the variable for the repository
@Autowired
private PersonRepository personRepository;
public Person findOne(String id){
return personRepository(id);
}
public List<Person> findAll(){
List<Hero> personList = new ArrayList<>();
Iterator<Person> it = personRepository.iterator();
while (it.hasNext()){
personList.add(it.next());
}
return personList;
}
//...
}
Is it really enough with declaring an empty PersonRepository extending from CrudRepository? No need to implement and say anything about each method of CrudRepository?. At least something to tell Spring about some constructor...
This doubt are all because I am getting this error when Spring tries to inject the personRepository variable:
Error creating bean with name 'personRepository': Could not resolve matching constructor (hint: specify index/type/name arguments for simple parameters to avoid type ambiguities).
Apparently, it is asking to have some class defining at least the constructor of the implementation. How do I tell Spring to avoid those type ambiguities mentioned in the error?