NDB Support in KAY

15 views
Skip to first unread message

Prateek Malhotra

unread,
Dec 30, 2011, 12:39:51 AM12/30/11
to kay-...@googlegroups.com
I was messing around with some of the new features in the NDB library that is now shipping with the SDK. I noticed the built-in forms feature in KAY breaks due to the lack of django form interfaces on the new Property class.

Before I start using too much of this, are there other areas of KAY that may break if I start to use the NDB library and move my code to utilize tasklets? I can continue to poke around and see what breaks but if anyone is more familiar with the framework that could give words of wisdom on using NDB with KAY, I'd greatly appreciate it.

Thanks,
Prateek

Paolo Casciello

unread,
Dec 30, 2011, 4:50:09 AM12/30/11
to kay-...@googlegroups.com
ndb is so new (and so experimental) that i don't think there's experience using it in kay. 
And it isn't a drop-in replacement for db so i think every middleware (i think about sessions, caching, auth..) could break if you change a model definition using ndb.

Btw, what do you think about it? So far i've only read the docs and tutorial and it seems good. It requires thus little code changes and some things i really don't like.. such as using a Key object to get a model... it's only a matter of code readability, not a problem in the code itself. 

Prateek Malhotra

unread,
Dec 30, 2011, 1:29:40 PM12/30/11
to kay-...@googlegroups.com
I have no intention in changing parts of Kay's built-in models to NDB, just curious as to the usage of KAY but using NDB for my own models. So far I found I can't create CRUD views for my models, a minor inconvenience but one none-the-less.

NDB has some strong features that I really like. Most importantly the tasklets. Instead of manually figuring out way to batch my fetch calls, NDB takes care of it for me with little effort on my part. I also think the simplification of functions is good and like the new Query interface although I was fairly used to the old way. Working with Expando models is also different now which is probably my only concern.

You can still use get_or_insert or get_by_id for fetching models, and I think using key.get() over db.get(key) is a bit more intuitive in that it gives a clearer view of how the key object differs from the actual entity and is more self-contained.

-Prateek

--
You received this message because you are subscribed to the Google Groups "kay-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/kay-users/-/I2DkDGecF5EJ.

To post to this group, send email to kay-...@googlegroups.com.
To unsubscribe from this group, send email to kay-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kay-users?hl=en.

Paolo Casciello

unread,
Dec 31, 2011, 5:00:23 AM12/31/11
to kay-...@googlegroups.com

Il giorno venerdì 30 dicembre 2011 19:29:40 UTC+1, Prateek Malhotra ha scritto:
I have no intention in changing parts of Kay's built-in models to NDB, just curious as to the usage of KAY but using NDB for my own models. So far I found I can't create CRUD views for my models, a minor inconvenience but one none-the-less.

Yes, i meant every time Kay uses your models. Forms, CRUD views and when you use custom models for authentication. And any middleware may use your models.

NDB has some strong features that I really like. Most importantly the tasklets. Instead of manually figuring out way to batch my fetch calls, NDB takes care of it for me with little effort on my part. I also think the simplification of functions is good and like the new Query interface although I was fairly used to the old way.

I agree completely.
 
Working with Expando models is also different now which is probably my only concern.

Expando are very good and I also like the strctured property and the new repeatable flag to manage lists of typed elements. (it's sorta like the kay's forms field).
 
You can still use get_or_insert or get_by_id for fetching models, and I think using key.get() over db.get(key) is a bit more intuitive in that it gives a clearer view of how the key object differs from the actual entity and is more self-contained.

I still prefer the model.get(key) syntax beacause if another developer reads the code is obvious the model class you will get. I'm little paranoid on code readability :D
But if we have two methods, one on the key object and another on the model, to retrieve it, it's ok!! :)

Happy new Year!,
 Paolo
Reply all
Reply to author
Forward
0 new messages