On 11/12/09 1:00 PM, Tim Hoffman wrote:
Hi

I have done some fairly extensive projects using traversal over a
relational model and we did use intermediate container classes alot.
Mainly because each major entity could have about 6 different classes
of sub items that we needed to group into containers anyway

I reverse engineered the entire relational model from the existing
database and then autogenerated all of the intermediate classes.
Quite easy to do.  I was using storm as an orm over the top, which
made things a lot easier
Hmm... still, this feels like an artifact to me. Presumably, in most cases what you want to return when the URL asks for a collection of sub-items is the very collection you already defined in your ORM on the model object that is the current context (we are using SQLAlchemy, BTW). I cannot help but think that there should be a way to automatically return an adapted collection that supports further traversal if necessary... but I'm not sure of all the ramifications of that idea.

Oliver

T

On Thu, Nov 12, 2009 at 7:43 PM, F. Oliver Gathmann
<gathm...@cenix-bioscience.com>  wrote:
On 11/12/09 11:03 AM, Tim Hoffman wrote:

Hi

I suppose it doesn't really matter how you go, and quite possibly the
deciding factor on why you might need
the wheel container and car container classes will depend on how you
access data,

For instance if you use something like zodb you can put arbitrary
entities inside other entities, (i.e someones/garage/beetle/frontleft)

where as  if you data is coming from a relational dbms the wheel
container class may in fact represent the table of all possible
wheels. and you
are using the beetle car to determine which instances of wheels
(wheels in the wheel table) that it owns.

That's precisely where we are coming from (we have a big legacy DB to deal
with).

If you have a really rigid relation model with a finite set of levels
then you may find you are creating arbitrary intermediate containers
just so you can define how you access the data. in this case maybe
routes may be a better alternative

Where as arbirtratry depth trees where each node can contain arbitrary
types (think of a filesystem containing many different file types or
potentially any depth)
really suit traversal as anything can probably be a container.

Oh - and I had hoped to be able to ditch routes now that I have model graph
traversal ;-). I'd say our relational model is neither rigid nor arbitrary -
we are constantly making changes but of course we stay within the limits of
our domain model.


Just my 2c worth.

I have to think some more about this, it seems - you 2c are much
appreciated, thanks!

Oliver

On Thu, Nov 12, 2009 at 5:40 PM, F. Oliver Gathmann
<gathm...@cenix-bioscience.com>  wrote:

Hello!

Coming from Pylons, I'm a newbie to the object graph traversal world, so
this question might be slightly misplaced (but hopefully a no-brainer for
the bfg gurus...).

I very much like the concept of looking up my model object before
dispatching to a view that operates on it. However, what bothers me about
the standard traversal algorithm is that, for a URL like

/cars/beetle/wheels/front_left

I have to promote the containers ("cars" and "wheels") to first class
citizens in my model (by defining CarContainer and WheelContainer classes
that I can then instantiate and return as the context object from the
parent's __getitem__), where in fact they are just collections held by their
mutual parent model objects (the Root object in case of the cars collection
- which is in itself artificial, but I'm willing to pay that price for
traversability - and the Car object in case of the wheels collection).

I guess I'm asking if there is a standard, "bfg-approved" way of avoiding
artificial container model classes - or did I just "not get it" yet?!

I'm very grateful for any hints and pointers you may have on this issue.

Thanks,

Oliver

--
--------------------------------------------------------------------
F. Oliver Gathmann, Ph.D.
Director IT Unit
Cenix BioScience GmbH
Tatzberg 47                       phone: +49 (351) 4173-136
D-01307 Dresden, Germany          fax:   +49 (351) 4173-109
--------------------------------------------------------------------

---------------------------------------------------------
Sitz der Gesellschaft (Place of Business): Dresden
Geschaeftsfuehrer (CEO): Dr. Christophe J. Echeverri
Amtsgericht (Local Court): Dresden, HRB 19964
Ust-ID (VAT-No.): DE205824437
---------------------------------------------------------



_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev



--
--------------------------------------------------------------------
F. Oliver Gathmann, Ph.D.
Director IT Unit
Cenix BioScience GmbH
Tatzberg 47                       phone: +49 (351) 4173-136
D-01307 Dresden, Germany          fax:   +49 (351) 4173-109
--------------------------------------------------------------------

---------------------------------------------------------
Sitz der Gesellschaft (Place of Business): Dresden
Geschaeftsfuehrer (CEO): Dr. Christophe J. Echeverri
Amtsgericht (Local Court): Dresden, HRB 19964
Ust-ID (VAT-No.): DE205824437
---------------------------------------------------------




--
--------------------------------------------------------------------
F. Oliver Gathmann, Ph.D.
Director IT Unit
Cenix BioScience GmbH
Tatzberg 47                       phone: +49 (351) 4173-136
D-01307 Dresden, Germany          fax:   +49 (351) 4173-109
--------------------------------------------------------------------

---------------------------------------------------------
Sitz der Gesellschaft (Place of Business): Dresden
Geschaeftsfuehrer (CEO): Dr. Christophe J. Echeverri
Amtsgericht (Local Court): Dresden, HRB 19964
Ust-ID (VAT-No.): DE205824437
---------------------------------------------------------



_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to