@IdPrefix (and other similar) annotations not working at all

Java SDK
1

I saw a sample usage of @IdPrefix (and other similar) here. I am trying to store a document in the DB but somehow the key is still without prefix (or suffixes that i use!)

Unlike in the above link, I am using ReactiveCouchbaseRepository to save the doc (rather than template). The following is the relevant code sample.

the model class

@Document
@Data
@EqualsAndHashCode(of = {"id"})
public final class User {

private static final String DOC_TYPE = "user";

@Id
@GeneratedValue(strategy = GenerationStrategy.USE_ATTRIBUTES, delimiter = "::")
@NotBlank
private final String id;

@IdPrefix
private String prefix = DOC_TYPE;

}

the test class

@RunWith(SpringRunner.class)
@SpringBootTest
public class UserRepositoryTest {

private static final User TEST_USER = User.createNew(Status.NEW, asList(new Profile(ProfileName.DOCTOR, Status.NEW)));

@Autowired
UserApplication.UserRepository userRepository;

@Test
public void shouldSaveUser() throws ParseException {
    final User user = User.createNew(/*...populate values, including id.../*);
    userRepository.save(user).subscribe();

    StepVerifier.create(userRepository.findById(user.getId()))
            .expectNext(user)
            .verifyComplete();
}

Here, post this method is executed, the doc stored does not have the prefix in the doc stored in the db. Any help would be appreciated. Thanks in advance.

2

@nilesh_ca, did this work for you ? I am also facing same issue . Could you please help me on this, if this has worked for you ?

3

Hi @lokendra1985rawat, which version of SDC are you using? Is there a public getter method for the field?

4

Hi @subhashni, I am using couchbase 6.0 enterprise version and is integrated with springboot 2.0, so i guess it would be latest version.

5

Here is an example, if the field is going to be still a part of the document, use @IdAttribute, and it is required that the id field is not set, if it is set by code, then that will take precedence,

@Document
public class User {

	@Id @GeneratedValue(strategy = USE_ATTRIBUTES, delimiter = "::")
	private String id;

	@IdAttribute(order = 0)
	private String firstName;

	@IdAttribute(order = 1)
	private String lastName;

	public String getId() {
		return this.id;
	}

	public void setId(String id) {
		this.id = id;
	}

	public String getFirstName() {
		return this.firstName;
	}

	public void setFirstName(String firstName) {
		this.firstName = firstName;
	}

	public String getLastName() {
		return this.lastName;
	}

	public void setLastName(String lastName) {
		this.lastName = lastName;
	}
}


User user = new User();
user.setFirstName("Alice");
user.setLastName("Smith");.userRepository.save(user);

the result document will have id Alice::Smith

6

@subhashni, thanks a lot, it worked.
I was passing id also as a part of json body .

8

Hi @subhashni,
One question regarding data fetching approach,

First Approach:

Let say I have two document

userdoc1
{
“status”:“pending”
“usertype”:“VIP”
“userid”:“123”
}
for above document let say my documentid is status::usertype
userdoc2
{
“userid”:“123”,
“fname”:“abc”,
“lname”:“xyz”,
“age”:20;
“address”:“asdf”
}
for userdoc2, let say userid is my documentid

If i do a get operation i would proceed like this ( here idea is to fetch data based on document id )
select userid from userdoc1 with key “pending::VIP”;
and then
select * from userdoc2 with key “123”;

Second Approach:

I have only one document

userdoc
{
“status”:“pending”
“usertype”:“VIP”
“userid”:“123”
“fname”:“abc”,
“lname”:“xyz”,
“age”:20;
“address”:“asdf”
}
Here, documentid is “status::usertype”
and we have secondary index on userid

Here if get the data like this( here idea is to fetch data based on secondary index ):

select * from userdoc where userd=“123”;

Could you please explain which approach will give high read performance assuming high data load with 100 of nodes in a cluster and XDCR and other factors ?

9

Hi @lokendra1985rawat,

The key generated “pending::VIP”, is it unique? Avoiding more index scans and network calls is better, but a different approach also might be better depending on the volume for each kind of documents.

10

@subhashni, It is just an example to showcase my in hand problem, in our case it is always going to be unique “pending::VIP”. I just want to know which approach is more efficient . Since first approach is based on documentid(which provide faster lookup than secondary index) but it involves 2 queries.
second approach involves one query but it uses secondary index.