problema Google Datastore com consulta sobre * usuário * tipo

Question

Na esta questão I resolveu o problema de consultar Google Datastore para recuperar o material por usuário (com.google.appengine.api.users.User) como este:

User user = userService.getCurrentUser();
String select_query = "select from " + Greeting.class.getName(); 
Query query = pm.newQuery(select_query); 
query.setFilter("author == paramAuthor"); 
query.declareParameters("java.lang.String paramAuthor"); 
greetings = (List<Greeting>) query.execute(user);

O funciona bem acima -, mas depois de um pouco de andar eu percebi esta sintaxe em não muito prático como a necessidade de criar consultas mais complicado surge - então eu decidi construir manualmente meus filtros e agora eu tenho, por exemplo, algo como o seguinte (onde o filtro é geralmente passado como uma variável de cadeia, mas agora é construído em linha para simplificar):

User user = userService.getCurrentUser();    
String select_query = "select from " + Greeting.class.getName(); 
Query query = pm.newQuery(select_query); 
query.setFilter("author == '"+ user.getEmail() +"'");  
greetings = (List<Greeting>) query.execute();

Obviamente, isso não vai funcionar mesmo se essa sintaxe com field = 'value' é suportado por JDOQL e funciona bem em outros campos (tipos de corda e enums). A outra coisa estranha é que olha o visor de dados no painel app-engine no campo 'autor' é armazenado como tipo Usuário , mas o valor é 'user@gmail.com', e depois novamente quando Eu configurá-lo como parâmetro (o caso acima que bem funciona) Eu estou declarando o parâmetro como uma string, em seguida, passando para baixo uma instância de usuário (utilizador) que obtém serializado com um toString() simples (eu acho).

Qualquer pessoa alguma idéia?

Answer 1

Usando substituição de cordas em linguagens de consulta é sempre uma má idéia. É muito fácil para um usuário para sair e mexer com o seu ambiente, e apresenta uma coleção inteira de problemas de codificação, etc.

O que havia de errado com a sua abordagem de substituição de parâmetro mais cedo? Tanto quanto eu estou ciente, ele suporta tudo, e evita quaisquer problemas de análise. Quanto ao problema de saber quantos argumentos para passar vai, você pode usar Query.executeWithMap ou Query.executeWithArray para executar uma consulta com um número desconhecido de argumentos.