Google problema con el almacén de datos de consulta de usuario * * Tipo

Question

esta pregunta He resuelto el problema de consulta de Google almacén de datos para recuperar cosas por el usuario (com.google.appengine.api.users.User) como esto:

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);

Lo anterior funciona bien - pero después de un poco de andar por ahí me di cuenta de esta sintaxis en no muy práctico como la necesidad de crear consultas más complejas surge - por lo que decidí construir manualmente mis filtros y ahora tengo, por ejemplo, algo así como el siguiente (donde el filtro está por lo general pasa como una variable de cadena pero ahora se construye en línea 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();

Es evidente que esto no funcionará incluso si esta sintaxis con field = 'value' es apoyada por JDOQL y funciona muy bien en otros campos (tipos de cuerdas y enumeraciones). La otra cosa extraña que se busca en el espectador de datos en el tablero de instrumentos app-engine el campo 'autor' se almacena como tipo usuarios , pero el valor es 'user@gmail.com', y luego de nuevo cuando lo configuro como parámetro (el caso anterior que funciona muy bien) estoy declarando el parámetro como una cadena a continuación, pasar por una instancia de usuario (usuario) que obtiene serializado con una sencilla toString() (supongo).

Cualquier persona alguna idea?

Answer 1

El uso de sustitución de cadenas en lenguajes de consulta es siempre una mala idea. Es demasiado fácil para un usuario para salir y meterse con su medio ambiente, e introduce toda una colección de problemas de codificación, etc.

Lo que estaba mal con su enfoque de sustitución de parámetros antes? Por lo que yo sé, es compatible con todo, y deja de lado cualquier problema de análisis. Por lo que el problema con saber cuántos argumentos para transmitir va, puede utilizar Query.executeWithMap o Query.executeWithArray para ejecutar una consulta con un número indeterminado de argumentos.