[Grok-dev] Re: sprint mini-report 6 (last day wrapup)

[Martijn Faassen]

Hi there,

Brandon Craig Rhodes wrote:
> Martijn Faassen <faassen at startifact.com> writes:
> 
>> If you want to be in on any of these topics, or want to propose 
>> other larger topics, please let us (or at least the driver) know.
> 
> I'm likely to be "driving", in the sense of continuing to post about,
>  the big issue of traversing when there is no hierachical database 
> behind Grok like the ZODB, and about what we should do as the number 
> of traversal rules and traversal shortcuts continues to grow and
> grow.

"grow and grow" is a bit strong given that we just added the first new
traversal rule to the system since somewhere before the second Grok
sprint, at least as far as I can recall. That goes back to early 2007. 
We added a new rule by codifying an existing pattern.

I don't want to stop you from exploring other forms of traversal and RDB
integration, but I want to make the case for exploring further how our 
existing traversal model could work with relational databases.

At the sprint we found that SQLAlchemy is perfectly able to make a 
hierarchical graph of objects, including mappings that act like 
containers. Making objects out of RDBs is what an ORM does for a living, 
after all.

There are nice aspects to this attept to let the ZODB model and the RDB 
model be similar:

* we're doing something that others aren't doing. That might be because
they thought it was a bad idea, but I suspect it's also partially 
because they didn't have a framework to actually explore this idea. I 
really want to push this model further as I have the intuition we have
will find benefits to this way of doing things, not just drawbacks.

* people who are switching between ZODB and RDB don't have to learn a
whole new paradigm of working

* some level of code portability: code that is written for a IContainer
will work with a RDB-backed container. Code that's written for a normal
model will work for an RDB-backed model (as long as the same interface
is implemented by both).

Of course someone who is used to a routes-based model will have to do
some wrapping their heads round this model. That's a drawback. But 
Grok's already unique enough already to bear the load of this uniqueness 
too, as this new uniqueness is actually not something new in *Grok* 
terms and could, hopefully, be turned into a strength.

> The beauty of adapter-based views, I think, really shines in the 
> context of something like a CMS, where, say, a Folder can appear 
> several levels deep at any location on the site.  This is quite 
> different from an RDB application, where you typically design exactly
>  one canonical URL pattern for each object; if every Person object 
> lives at a URL "/person/<id>", then one might as well go ahead and 
> define the possible views along with the URL.

Typical RDB frameworks encourage this design. Doesn't mean we have to do 
the same here.  Our current working sketch of megrok.rdb introduces less 
new ways of doing things to Grok itself than a routes style approach.

What interests me is the reports by several people (including you) of 
"spaghetti traversal". I'd like to analyze this further. I propose that 
besides talking about major philosophical shifts when a RDB is involved 
to avoid these problems, we also look for solutions that allow us to 
reduce these risks within the framework of our current approach.

I still need to understand more about what was wrong for people trying 
to match traversal model and ending up with this spaghetti. I know there 
was the problem of the same object being on different URLs, and not 
having a canonical URL in that case. I want to understand that and 
related problems better.

Regards,

Martijn