Comments for Topp Engineering

Comment on To ZODB Or Not to ZODB by Andy McKay

Andy McKay — Fri, 09 Apr 2010 22:01:01 +0000

I’m not sure if I make that complaint against all the NoSQL storages. I’m taking the lessons I learned from the ZODB and making sure I don’t repeat the mistake in the future by examining the options available.

Comment on To ZODB Or Not to ZODB by Paul Winkler

Paul Winkler — Fri, 09 Apr 2010 16:58:14 +0000

Andy McKay makes the “no ad-hoc queries” against not only ZODB, but all the “NoSQL” storages:
http://www.agmweb.ca/blog/andy/2254/

Comment on To ZODB Or Not to ZODB by Paul Winkler

Paul Winkler — Mon, 22 Mar 2010 14:47:26 +0000

Oh, and ricoPan, to answer your direct question, all current TOPP python projects are using something other than ZODB. We’re rapidly phasing out our involvement with all things Zope-related. We’re doing lots of Django; some Pylons + SQLAlchemy. The OpenGeo team mostly uses PostGIS accessed via GeoServer and/or GeoDjango. One Java project is using Java Serialization.

Comment on To ZODB Or Not to ZODB by Paul Winkler

Paul Winkler — Mon, 22 Mar 2010 14:40:42 +0000

ricoPan - I glossed over this in the original post, but you actually can do something like lazy loading of attributes, just not in an ad-hoc manner. All you have to do is make those attributes be something that inherits from Persistent. So for example, instead of a dict, use a PersistentDict or (better) OOBTree or one of the other *BTree classes.

Once you start doing that though, your model code doesn’t look quite so beautifully transparent. And you get lazy loading all the time for all instances of your class … you can’t be selective about that. It’s a tradeoff.

I’m curious, have you considered any of the “NoSQL” databases such as CouchDB? You can’t store arbitrary python objects of course, but dicts and lists are dead easy.

Comment on To ZODB Or Not to ZODB by ricoPan

ricoPan — Sat, 20 Mar 2010 15:57:53 +0000

Still out there with ZODB? I’m wondering if you have changed. I’m thinking of going the other way, having used SQLalchemy, which is beautiful, but I need to query over more complex python objects such as dicts and lists, and I’m sick of representing these ad-hoc in sql. These queries don’t need to be super fast — it was the speed concern that pushed me to a rel db in the first place, but that may not have been the right choice.

If I could retrieve a few attributes of an instance rather than the whole thing I think ZODB would work for me out of the box. As it is, I need finer control of attribute management (attributes too big and must be lazy loaded).

Comment on topp and django by Nick Grossman

Nick Grossman — Wed, 04 Nov 2009 17:46:11 +0000

Yeah, it seems like this is a good direction. I am particularly intrigued by the way that pinax makes it easy to do the basics — I feel like we’ve spent way too much time in the past building signup forms and password reminders.

Comment on topp and django by Paul Winkler

Paul Winkler — Wed, 04 Nov 2009 02:13:10 +0000

I know Rob knows this, but some people might not: http://fixcity.org is a Django app.

Comment on topp and django by nicholasbs

nicholasbs — Tue, 03 Nov 2009 23:40:03 +0000

Dave and I use Django for BusTracker: http://github.com/novalis/BusTracker

No complaints from me. It’s easy to work with and the geo support seems quite good.

Comment on topp and django by whit

whit — Tue, 03 Nov 2009 21:32:58 +0000

Pinax was pretty impressive when the GeoNode team was trying to decide what web framework to use. Arguably, though we aren’t using it yet, the prospect of it’s use was at least one argument for our choice of django.

Comment on topp and django by Rolando

Rolando — Tue, 03 Nov 2009 19:15:01 +0000

We had similar discussion about Django and Pinax here on the OpenGeo side of the hedge a couple months back. We’re now using Django as the web framework behind our new GeoNode project. You should ask Seb, Dwins, or Whit about it if you are curious.