> 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. >
I don't see how that is irrelevant, as it makes your statement incomprehensible. I can't infer what you really meant. > 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. > First, in this case I was talking about a reference field, which references a *single* foreign record -- there is no sequence of objects in this case, not even in an ORM. If you go in the other direction, however, a DAL LazySet does in fact reference a sequence of records. In any case, your reasoning applies just as well to an ORM -- the attributes that are objects are themselves merely intermediate objects on the way to scalar values stored in the database -- so I guess we cannot grant them "non-scalar" status either. > 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. > Well, I'm not 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). > Yes, but you act as if all the data are always magically there without any database queries. There has to be an initial query (or set of queries) to get the data from your database in order to populate the instance objects to begin with. The SQLA session lasts only for a single web request, so this has to happen at every request anyway. Furthermore, if you need to issue a query that happens to require the same records you already have in the session, it still needs to do a database select again (unless you query specifically by primary key) -- the DAL, on the other hand, can cache queries, even across multiple web requests. Yes, in web2py, if you need to apply the same recursive select twice, it will hit the database twice (unless you cache or store the result), whereas SQLA will generally do only one select. On the other hand, in web2py, you might simply do a join, in which case, you have all the related data and don't need any subsequent selects. 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. > Note, this is not unique to an ORM and can be done in a DAL as well. The web2py DAL does this, albeit exclusively with lazy loading, though presumably an eager loading option could be implemented as well. > So saying that any attribute-access would "necessarily-always" generate a > "select" is inaccurate. > Right, so good thing I didn't say that. > 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's not quite that simple. You have to make some decisions, and there are tradeoffs. By default, the SQLA ORM does lazy loading of reference records (i.e., it issues a separate query for each reference attribute accessed) -- same as web2py recursive selects. This is more efficient if you only need to do this on one or a few instances. The ORM can also optionally do eager loading, either with a join or a second subquery, both of which have their advantages and disadvantages. In any case, you are not guaranteed to get the minimum-required database access automatically. > 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... > No, the purpose of list:-type fields is not to mimic ORM behavior, nor are they absurd. If you need to store lists but don't need the benefits of a relational design, they can be simpler and more efficient. > 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... > I wasn't arguing that list:-type fields are web2py's version of the above (which web2py implements as well) -- just pointing out yet another non-scalar abstraction. > 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. > Not at all. web2py already provides attributes to handle the relations, as already described. If you believe the web2py Reference and LazySet attributes qualify only as scalars, then so do the SQLA ORM relationship attributes, as they both ultimately retrieve scalar values from the database. I was making a separate point that web2py method attributes can be complex objects, as you seem to think that is important. Also, note that DAL LazySets allow you to apply additional query filters and to select only specific fields as well as expressions -- not sure that can be done via a SQLA ORM relationship attribute. For what it's worth, I like some of these features of the SQLA ORM, and I wouldn't mind having them in web2py. One question, though, is whether these features really require an ORM. It seems that a lot of this behavior could be built into DAL Rows and Row objects (e.g., eager loading of relationships, caching of lazily loaded relationships, statefulness). Another question, of course, is whether the development effort would be worth the benefits (which may be modest and limited to special cases). 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.
