You are right, the driver does not use ReferenceProperty, but uses IntegerProperty for all references. ReferenceProperty is a convenience for the AppEngine ORM and is not needed in web2py DAL, and would be incompatible with the SQL tables.
Originally, gql.py generated GQL and passed it to GQLQuery which parsed it and generate the Query object, the GQL was stored in _last_sql and _select() could be used to view the GQL of the last query, but now gql.py uses the Query object directly to programmatically generate the query, so there is no GQL generated or parsed. It would be possible to add more debugging information to the last_sql since the information is available (filters, orderby, limitby), but its not formatted or presented like GQL. Robin On Jan 2, 11:16 am, "sudhakar m" <[email protected]> wrote: > Thanks Robin for a detailed explanation on HABTM vs ListProperty. > > db.define_table("Match", > > > > > SQLField("ground", "string"), > > SQLField("result", "string")) > > > db.define_table("Team", > > SQLField("name", "string")) > > > db.define_table("Player", > > SQLField("name", "string")) > > > db.define_table("TeamMembership", > > SQLField("team_id", "integer"), > > SQLField("player_id", "integer")) > > > db.define_table("MatchMembership", > > SQLField("team_id", "integer"), > > SQLField("match_id", "integer")) > > I will probably stick with this model for now as ListProperty restriction of > 5000 items might cause some problems in the near future. > > > db.define_table("TeamMembership", > > > SQLField("team_id", "integer"), > > SQLField("team_name")) > > SQLField("player_id", "integer") > > SQLField("player_name")) > > I certainly agree on this. De-normalization is very much required in my > case. > > But, added to GAE in August, batch > > > writes across entity groups ( > >http://googleappengine.blogspot.com/2008/08/couple-datastore-updates.... > > ) so now you could add/remove N items from a membership in parallel > > with one batched write from your end (web2py does not support this). > > To start with there will be very few writes in my case. But I have a > scenario where a single record in player table gets updated frequently (say > one update/min for a record). So at any point in time there wont be more > than say 5-6 records updated per min. I guess this shouldnt be a problem > > One more thing that concerns me is in gql.py, I could only find > 'reference':google_db.IntegerProperty, defined for SQL_DIALECTS. So arent we > using the gae's *ReferenceProperty*? (my apologies, I still dont fully > understand the code yet ;) ) > > Once I have a full grasp of gql.py, I am planning to modify it in such a way > that it makes use of all the gae's special features. I am certain that it > will require many changes which will play nice with rest of web2py. By this > way we will have a webframe work that fully supports gae. Other's who are > not using gae for deployment can safely ignore it. Only catch here will be > that the portability will be lost for such applcation. > > Is there any way to find out what code web2py is generating for gae (yep I > am looking in to the code already) > okie let me dig little deeper to find out how it actually works > > Thanks, > Sudhakar.M --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
