I am not familiar with listproperty but how does this (http:// groups.google.com/group/web2py/browse_thread/thread/1ac0b91d25047aa0) differ from it?
Massimo On Jan 4, 2:34 pm, James Ashley <[email protected]> wrote: > On Jan 4, 11:56 am, mdipierro <[email protected]> wrote: > > > > I'm using google's raw datastore api (google.ext.db). I gave up on > > > web2py's style of models when I really needed a ListProperty of > > > KeyProperty's. > > > Have you checked out the latest IS_IN_DB(....multiple=True)? > > I do not think it is very different than the ListProperty. > > In all fairness, I have not. I have seen posts discussing it, and > I've taken a quick glance at the code. > > It's more a gut reaction based on [very limited] experience and > exposure to issues I see on the GAE mailing list. Well, those and a > lack of time. > > IS_IN_DB seems to solve other issues than the ones I've run across, > though (I could very well be misunderstanding its use). > > In one example, I have an ACL of users/groups allowed to do various > things. Under each security condition, I keep a ListProperty of User/ > Group keys. If one of those keys matches the currently logged-in user > (or any of the groups the user's in), the user can do whatever that > permission level allows. I'm leaning toward storing the user's ACL > rights as a pickled BLOB instead (in a record corresponding to each > user), but, for now, this is performing acceptably. > > I switched to doing it that way a few months back, because I couldn't > figure out how to do it at all with web2py's ORM. > > In another example, I have a tree data structure. Child nodes contain > reference nodes to their parent nodes. The parent node has a > BooleanProperty to indicate whether it has any children (this is used > in the tree view to indicate whether a given node can be expanded or > not). Since ReferenceProperty's work both ways, I can get the Node's > children in a single query when the client tries to expand a node. > > Before I switched to that method, App Engine timed out all over the > place. > > I'm tempted to de-normalize that as well, but I also query directly > for child nodes, and I want to avoid the duplication as much as I can. > > Anyway, looking through the newest sources, it looks like the id > column has been switched to use GAE's key, so maybe these use-cases > could be converted back without much overhead. > > Please don't anyone read this as any sort of criticism of web2py's > ORM. Far from it. The fact that web2py runs on GAE out of the box > puts it way ahead of any comparable framework (including Google's old > crippled version of django) that I've been able to find. > > I almost always wind up putting a wrapper layer over any data access > layer I use, almost out of habit. I've had to change those so many > times that I don't even really think twice about that particular > step. I made the engineering trade-off decision to switch to google's > ORM a few months back, because it made the most sense for that > situation at that time for that current project. > > Based upon Sudhakar.M's description, I suspected that he'd run into > many of the same issues, so I recommended he run some tests and > benchmarks to see. > > (One of the GAE trade-offs, as far as I've been able to tell, is that > performance doesn't seem to vary much with the size of your data > store, though it does with the size of your results. So querying a > few thousand records should give you a fairly accurate benchmark. I > really should check that assumption). > > I have found that working directly with their API has given me a much > better feel for what works and what doesn't. It's easy enough to say > that it isn't an RDBMS. It's a lot harder to break years' worth of > habits of thinking in RDBMS terms. (I still see at least 2-3 posts a > week on their mailing list of new developers complaining that queries > time out, but they aren't willing to de-normalize their data). > > Actually, thinking about it from that perspective, it seems like > another good reason to not use web2py's ORM. If/lwhen I do switch to > a different platform, I'll also be switching back to an RDBMS. Which > will involve a fairly hefty database re-design, no matter which way I > look at things. I'll be far less likely to miss something if I have > an obvious re-write where anything I miss will break immediately. > > Sorry for the long babble. These are issues that I keep circling back > and questioning myself about. > > Regards, > James > > > > > Massimo > > > On Jan 4, 11:37 am, James Ashley <[email protected]> wrote: > > > > [This is starting to veer *way* off-topic, and might be more > > > appropriate on the GAE list. My apologies] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
