Develop Reference

Objectify: How can I have a unique ID across several types?

I have a few types that have a common field(Email ID) that I am using as an #Id. These types extend from a common type User which has the Email ID field. It is something like below:
#Entity
class User{
#Id
String emailID;
}
#Entity
#Subclass(index = true)
class UserType1 extends User{
String otherField;
}
#Entity
#Subclass(index = true)
class UserType2 extends User{
String otherField;
}
Now, I want that every time I insert a subtype of User, the Email ID should remain unique across all these subtypes objects in the datastore. I tested an endpoint for the above types by inserting each of subtypes with the same EmailID and it happened successfully - Objectify shouldn't have allowed the persistence of subtypes with the same ID. As per my understanding, the ultimate uniqueness is ensured by the keys but can't I ensure uniqueness by an Id across just the subtypes especially when ID is in the base class? Is there some way to do it?
EDIT:
Although, this is not the solution I was looking for, I have handled this situation by creating a new entity type with {EmailID, Key_Subtype} which worked in ensuring the uniqueness. I just check this entity for existing emailID and I use the key for retrieving the object with another query.
If anyone comes off with a better solution, I would appreciate it.

UUID is that what you are looking for. It is generated for each entity. Type does not matter.
https://dzone.com/articles/hibernate-and-uuid-identifiers

Same Id for different entity types is definitely possible at the datastore level, see re-using an entity's ID for other entities of different kinds - sane idea?
The Id uniqueness is only guaranteed across entities of the same kind and with the same parent entity (the unique entity key is based on a combination of these 3 items). Since your subtypes are actually different entity kinds there is no problem having the same Id across these kinds, so subclassing is not the way to achieve what you want.
To have unique Ids you need to have a unique entity kind, say User. To distinguish the different user types maybe have inside User a type property which would be a reference to a entity of UserTypeX kind containing the info specific to that user type?

It sounds like you have found the "correct" solution - create an Email entity that uses the email address as the id and contains a pointer to the appropriate User entity. When creating a new User/Email, always check for pre-existence of the email address in a transaction.
This really isn't any different from using the email address as the id of the User directly except that the extra layer of indirection allows users to change their email addresses, which is generally a good idea. The transactional logic is similar either way.
Transactionally looking up & creating an entity with a natural primary key is pretty much the only way of guaranteeing uniqueness in the datastore. It is effective and scalable.

Validate Search Criteria : Java

I have to implement search based on almost 12 different fields.
For validation and processing, I am facing a lot of challenges. Following are those with which I am seeking inputs/help.
Classes:
SearchCriteria
(has) UserCriteria and AddressCriteria
PS. A few fields are related to user e.g. First Name, Date of Birth etc. which goes in UserCriteria and a Few fields are related to address e.g. Street Name, Building Number etc. which will go into AddressCriteria
Based on these criteria I have to search users.
Validate that at least one parameter is not null/not empty. I do not
want to keep checking each and every field for null and emptiness.
Before search validate based on which criteria you need to initiate
search. e.g. User or Address?
Implement validations such a way that you need not to worry about
specific field validation before adding it in query criteria
EDIT:
NOTE : I need to prepare a message with all the valid fields which will be passed to the module which helps me finding all records, I am not dealing with DB directly.

What if both of your objects (UserCriteria and AddressCriteria) has a method like,
public ArrayList<String> getSearchableFields() {
//return a ArrayList of searchable fields
}
Then you'll be able to call getSearchableFields() on each method and see what fields are available to use for your search.

Does it make sense to create entity table with only ID attribute?

Does it make sense to create a single entity when it should only contain the #Id value as a String?
#Entity
class CountryCode {
#Id
String letterCode; //GBR, FRA, etc
}
#Entity
class Payment {
CountryCode code;
// or directly without further table: String countryCode;
}
Or would you just use the letterCode as the stringvalue instead of creating the CountryCode entity?
It should later be possible for example to fetch all payments that contain a specific countrycode. This might be possible with both solutions. But which is the better one (why)?

Yes you can if you are using the entity as a lookup. In your example, you may want to add a column for description congaing (France, Great Britain, etc.) for the letter code and a third column whether it is active or not and maybe columns for when inserted and when it was last changed.

It makes sense to create such table to provide consistency of data, that is that no Payment is created with non-existing CountryCode. Having a separate entity (that is table) together with foreign key on Payment allows checking for consistency in database.
Another possible approach is to have check constraint on the code field but this is error prone if codes are added/deleted and/or there are more than one column of this type.

Adding the letterCode the the Payment Class as String Attribute (Or Enum to prevent typo errors) will increase the fetch performance as you do not need to create a join over your CountryCode Table.

solrj: how to store and retrieve List<POJO> via multivalued field in index

My use case is an index which holds titles of online media. The provider of the data associates a list of categories with each title. I am using SolrJ to populate the index via an annotated POJO class
e.g.
#Field("title")
private String title;
#Field("categories")
private List<Category> categoryList;
The associated POJO is
public class Category {
private Long id;
private String name;
...
}
My question has two parts:
a) is this possible via SolrJ - the docs only contain an example of #Field using a List of String, so I assume the serialization/marshalling only supports simple types ?
b) how would I set up the schema to hold this. I have a naive assumption I just need to set
multiValued=true on the required field & it will all work by magic.
I'm just starting to implement this so any response would be highly appreciated.

The answer is as you thought:
a) You have only simple types available. So you will have a List of the same type e.g. String. The point is you cant represent complex types inside the lucene document so you wont deserialize them as well.
b) The problem is what you are trying is to represent relational thinking in a "document store". That will probably work only to a certain point. If you want to represent categories inside a lucene document just use the string it is not necessary to store a id as well.
The only point to store an id as well is: if you want to do aside the search a lookup on a RDBMS. If you want to do this you need to make sure that the id and the category name is softlinked. This is not working for every 1:n relation. (Every 1:n relation where the n related table consists only of required fields is possible. If you have an optional field you need to put something like a filling emptyconstant in the field if possible).
However if these 1:n relations are not sparse its possible actually if you maintain the order in which you add fields to the document. So the case with the category relation can be probably represented if you dont sort the lists.
You may implement a method which returns this Category if you instantiate it with the values at position 0...n. So the solution would be if you want to have the first category it will be at position 0 of every list related to this category.

Domain Driven Design - How to use value object on the UI

I was wondering how you use your ddd model within a web application. Within Eric Evan Cargo application there's the Cargo class which contains the value object Itinerary. Within Itinerary is a collection of Legs, again a value object. All value objects hide the surrogate id to the outside world.
So when using this domain model, how would I create a web app, where you can click on a cargo itinerary, list all legs and then show the details of a leg by redirecting to a new "leg detail" page. Usually I would pass the LegId within the query fields and read it out again on the detail page. But since it has no id, how would you do that?
Using the index of a leg which might change when the collection gets sorted?
Passing all values within the query fields since this is the value object identity?
Sounds like a step backwards to me :)

If the leg has no id, the only way you have to refer to it is through the Cargo, which has an identity, and therefore can be associated with a URI/URL. To refer to a specific leg, you have only the index, which can be a number, or a dictionary key. If you have sorting issues, you can define two lists: one with the canonical ordering for reference purposes, and another with the ordering, mapping order position and canonical index.
As for the reason why the value objects in Evans' example have ids, I think it's for serialization purposes.
Of course, you can also opt for a Itinerary/Leg with identity.