On Thursday, May 2, 2013 5:17:41 AM UTC+3, Anthony wrote: > > > 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. > >
The operative word in my comment is *SET *not *FIELD. * I may have gotten the Field-vs-Record terminology in this sentence, but that is irrelevant to what I was referring to. My point was that the assertion of wikipedia that ORM can have references to non-scalar values, applies in your example, as the existence of intermediary-objects on the way to get to the value, does not grant the attribute "non-scalar" status - only a reference to a *SEQUENCE *of objects can do that. > >> >>> 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. > No. that is not what I am saying, although that might occur if you configure it to behave like that. But the flaw in your reasoning is that you are trying to apply a "stateless-mid-set" to a "statefull-system". I'm not sure why you are doing that. When you say "automatically selects" you are meaning to say "automatically generate queries", because within a stateless system there is no record-cache-management, so any access to an attribute IS a "select" from the database. But that is not the case with statefull-ORMs - they "may" issue selects "if-and-only-if" the requested value is "invalid" (meaning, it was either never queried at all as of yet, or was invalidated by a previous transaction-commit). Attribute-values along the object-graph, "may-or-may-not" be valid, and so "may-of-may-not" require a "select". When you use a statefully-automatic system, you are deliberately relinquishing (at-least-some) control over such matters, in favor of not having to worry about whether a given attribute-access would need to occur or not. You make an object-attribute access, and the ORM is traversing the object-graph that is linked to this attribute, in order to get a value at some point. The ORM is doing the traversal for you. If all of the objects and attributes that are traversed over, are "valid" (a.k.a "exist and are up-to-date"), then no select would have to be sent to the database. Again, in an ORM you are building your object-graph "up-front", using domain-classes. It just get's "inhabited" and "updated" for you, as you use it. So saying that any attribute-access would "necessarily-always" generate a "select" is inaccurate. Also, it is not necessarily inefficient, as the idea in an ORM is that it figures-out the minimal-required database-access in order to get you the data you ask. It may NOT "query" entire sets of records, if you only need "some" of them (here a DAL layer underneath is taking care of that, generating optimized queries for you, an/or using queries that you have defined for it to use). And again, in subsequent access to the same attribute, it would again traverse the same object-graph linked to it, and this time, all the objects/attributes that where previously missing and queried, are now caches-and-valid, so no database-access is performed. > >> >> >>> 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. > It is amazing how far the DAL features have gone to mimic an ROM "on the surface", while not being the real thing underneath.... You are basically suggesting "bypassing" the relational-functionality of the database, and do it in the DAL, all just to achieve "appearance" of an ORM... I don't even know where to place that... It's absurd... An ORM object-graph is a representation of foreign-key relationships in the database - not a relation of sub-values stored in some "string"-type value... An ORM object, may have a value that is a representation of foreign-table-fields that point to it via a foreign key. It is a "real" non-scalar-relation in both the database AND the object-attribute - not some kind of a framework-hack... > > >> >> 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. > In order to do that, you would have to "replicate" the relations (that already-exist in the database) in code, and construct-that on every assess to that attribute - instead of "using" the relationships that already exist in the database, and have them "automatically" generating an object-graph for you "once", in application-launch time. Which would you say is more efficient? Which would you say is more easy to use? Which would you say is more maintainable? > > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
