> Although ORM's may do that, such a feature is not unique to the ORM >> pattern. In the web2py DAL, for example, in a Row object with a reference >> to another table, the reference field is actually a DAL.Reference object, >> not a scalar value (it includes the scalar value but also allows access to >> related records in the referenced table). >> > > In this case it does not reference a set of DAL fields. >
I'm not sure what you mean. A reference field references records, not fields. > > >> Similarly, a Row object from a table that is referenced by another table >> includes an attribute that is a DAL.LazySet object (also not a scalar), >> which allows access to the records in the referencing table that reference >> the current Row object. >> > > I did not know that - what form of *Layziness* are we talking about here? > Will it generate a query to fill-up the target rows? > In any case, it is stil a reference to something the WOULD generate a Rows > object - it is not a reference to an already-exising domain-object (which > may then have references to othe domain-objects, etc. - all already within > memory) object as is in ORMS > Are you saying that when you select a set of records that include reference fields, the ORM automatically selects all the referenced records (and any records they may reference, and so on) and stores them in memory, even if you have not requested that? That sounds inefficient. > > >> The DAL also has list:-type fields, whose values are lists, including >> lists of DAL.Reference objects in the case of list:reference fields. >> > > That's interesting, but that is not exactl the same - list-fields need to > be supported in the database, but in any case, it is not comparable to > being linked to relation ally-stored primary-keys - which would be how it > would be implemented in an ORM. > No, list fields do not have to be supported in the database (they are stored as strings) -- they are an abstraction provided by the DAL. list:reference fields do in fact store a list of primary keys (in fact, a list of objects that include the primary keys and know how to retrieve the associated records). web2py also has JSON fields, which I would say does not count as a scalar either. > > Row objects can also include custom methods (i.e., "lazy" virtual >> fields) as well as virtual fields, which can contain complex objects. >> > > Relates to the comment I gave you a couple of minutes ago... > These are complementary-auxiliary features (with in the > web2py-implementation case, have questionable real-world-utility) which > while they do go beyond a "simple" value, they are still scalar, as they > ultimately result in a reference to a scalar-value - not a reference to a > sequence of objects. > No, you can define a virtual field whose value is any custom complex Python object you like, with its own methods, that may do or return whatever you like. They need not reference or return a scalar value. This is not a mere "auxiliary" feature but something that allows you to replicate functionality you might otherwise find in an ORM class. Anthony -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
