JDO Google App Engine 验证用户
我一直在关注谷歌应用程序引擎教程,解释 JDO 的部分是在留言簿的基础上完成的。因此,当他们查询持久性(我相信是 BigTable)时,他们有兴趣返回所有结果。
我正在尝试调整它以显示特定用户的结果,但似乎遇到了问题。
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
if(user != null) {
PersistenceManager pm = PerManFac.get().getPersistenceManager();
String query = "select * from " + Team.class.getName();
List<Team> teamList = (List<Team>) pm.newQuery(query).execute();
if(teamList.isEmpty()) {
这是我到目前为止所拥有的一部分,我需要将查询字符串调整为“where User = user”,但每次都会遇到问题。
我的团队对象仅包含密钥、用户、字符串和日期。
I've been following the google app engine tutorial and the part that explains JDO is done under the basis of a guestbook. So when they query the persistence (BigTable i believe) they are interested in returning all the results.
I'm trying to adapt this for showing the results for the specific user but seem to be having trouble with it.
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
if(user != null) {
PersistenceManager pm = PerManFac.get().getPersistenceManager();
String query = "select * from " + Team.class.getName();
List<Team> teamList = (List<Team>) pm.newQuery(query).execute();
if(teamList.isEmpty()) {
Thats part of what i have so far, i need to adapt my query String to be 'where User = user' but i get issues each time.
My Team object only holds Key, User, a String and Date.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您无需 JDOQL 即可完成此操作。如果用户只有一个团队,那么您可以使用 拥有一对多关系,这是双向的。
要获取
员工
,您可以通过电子邮件查询:如果用户可以在多个团队中,您需要使用 无主关系。根据您的描述,听起来每个团队都有一个用户(?),因此您可能需要一种无主的多对多关系。
没有详细记录的部分是您不能使用
User
对象作为主键(主键的可能类型相当有限),因此您最终经常使用电子邮件作为主键。User
对象可以是一个字段,但为了使数据模型保持一致,您通常要么在各处使用电子邮件来引用用户,要么像我上面那样使用包装器对象。You can do this without JDOQL. If a user only has one team, then you can model this with an owned one to many relationship which is bidirectional.
To get the
Employee
you can query by email:If a user can be in many teams, you need to use an unowned relationship. From your description, it sounds like each Team has one User (?), so you might want an unowned many-to-many relationship.
The part that isn't really well documented is that you cannot use a
User
object as a primary key (the possible types for a primary key are quite limited), so you end up often using the email as the primary key. AUser
object can be a field, but to make your data model consistent, you often either use the email everywhere to refer to the user, or you use a wrapper object like I did above.