> Now, you might argue that this is just a bad example, and that there is > some real-world example where the web2py DAL will be forced to do something > like you have coded here, and that's where the ORM will have an advantage. > If that's the case, then you should have no problem presenting such an > example. If you cannot do so, then it is hard to take this seriously. >
My difficulty/reluctance to finding more/better examples, are a testament to my poor expertise Nothing more, nothing less. > > As far as I can tell, if you want to update a record in SQLA, you must > first retrieve it from the database (if using the ORM). If you believe that > is not the case, then please show the code for how you would do this in the > ORM. > I am already stretched way beyond my expertise, here, which is an interesting exerciser, but I can't stretch that to the point you are asking me to. I see no logical-fault in my suggestion, so irrespective of where this logic is implemented, irrespective of weather it is implemented in SQLA, and irrespectively of my ability to implement a prototype that would do that, the logic appears to be sound. There is no logical-reason you could not generate an object-graph out of the query you are constructing, Only the benefits of that are questionable, and that may be extremely circumstantial and complicated to benchmark, so U am not going to do that. There are other people (presumably in this group as well), who are much more proficient and experienced in doing so. I will elaborate on where I think my logic is sound, further on, and show you what you are missing. > > As for the architectural issue, I suppose in principle an ORM could update > a record without a prior select, but then you lose the other benefits of > the ORM, as you will not have an object representation of that updated > record in Python. > You are assuming a circumstancial-implementation that is not doing what I have suggested. If the update operation would generate an object-graph, representing what it is assuming is existing in the database "schema wise", then I see no reason why it should not be able to store the data tha it is udpating (or even inserting). Remember, we are talking about a context of an atomic transaction, so an ORM is logically safe in assuming that the transaction will complete successfully - it's called "optimistic updates". The reason for this safety, is that the object-graph that is being created in the transaction is being tracked, so a rollback, in an event of transaction commit-failure, is going to dump these object anyways... More so, the ORM is aware of the database schema, so it could infet the validity of the structure of the object-graph it would generate. > At this point, you might as well have a DAL. In other words, if both the > ORM and the DAL handle this case via direct database updates, then this > example is irrelevant for establishing the supposed advantages of an ORM. > True for SQLA. Not true in what I am proposing. > > In web2py, you create the objects when you need them. You do not always > need them. For example, if you are updating a record, you might retrieve it > in one request, then update it in a second request -- no need for another > retrieval in the second request (unless you want to check for intervening > changes). > What I meant by that is that this example is not showing much reuse within the same transaction, so your argument that object-creation, may not be that beneficial, is valid in this example. However, the whole point in having an ORM, is for cases you DO have many reuses of record-objects within a transaction. In these cases, an ORM is more beneficial. In other cases, thr DAL would be more beneficial. The mere fact that even with an ORM, there would still exist circumstances in which it would be less efficient, is not a testament to the ORM's uslessness... By that logic, the mere existence of circumstances in which "walking" would be more efficient than "driving a car", is somehow a testament to a car's uselessness... For circumstances in which the DAL would be more efficient - by all means "use it" - it is not going anywhere (!) That's what SQLA users are doing (at leas I hope...) Again, it is only a testament to the poorness of my example - that's it. > > No, in web2py, you do not need to create a Row object in order to update a > record in the database. > I meant the objects that the DAL is creating for it's internal functionality - on the fly - they are akin to the objects that an ORM would create to implement it's functionality - on the fly... The fact that an ROM would create slightly more record-objects than web2py would create, it not necessarily a bad point for an ORM - again, you can dissect any framework and find inefficiencies linke that everywhere, if you like - it may mean something and may not - there are multiple trade-off being taken in multiple levels, for the "greater good" so to speak - you need to look at the big picture to make such judgments. In THIS example, assuming that all my assumptions are true (which you may not at this point, but we'll get there), than it may be worth it, if an extra trip to the database would be knocked off. If not, then I'm sure there are cases like this, otherwise such investment would not have been made in ORMs. Granted, even then there will-be occasions in which it would be less efficient - for that, there may be 2 solutions - bypass the ORM and go to the DAL, or devise a way to make it more beneficial, or at the very least, not-less beneficial - but those are issues of further refinement of the framework. > Not sure what you're talking about here. If you are talking about defining > tables in web2py at every request, it is not required that you define all > the tables for the entire schema -- you can define conditionally depending > on what you need. If you are talking about creating instances of Row > objects, then you are mistaken -- only those you explicitly create are > created, and exactly when you explicitly create them. > You are right, but see above (contex: bigger-picture) > > Yes, and my point was that we're already done optimizing because there is > a better approach in the DAL. If you have an example where your proposed > optimization would really be the only way, please show it. > > Boy, this is pure traw-men now,.. You are taking my sentences out of context and so muting their meaning. That sentence was said in the context of my assumption - not -yours - and even more, as a stepping-stone to see what will NOT work, not what will - the fact that there may be another reason for not doing that, is not concluding that my logic was faulty. What more, even if my assumptions where faulty, then the argument would be on those assumptions, not on the conclusion. A statement may sill be "valid", if the conclusion is true, even if the premises are not - the problem would then be with the premises, not the conclusion, nor the inference. This is basic logics-stuff - catch up with it: http://youtu.be/99l6NCL24Ek So let's stay focused here, again - our argument is on the premises, not the conclusion - at least in this case. > > Well, that's a problem, as it means you are assuming it is feasible to > build an ORM with some magic behavior without being able to point to any > existing implementation of such behavior. > It is not magical-behavior, it is a logical one - and the absence of implementations, has nothing to do with the logic of it. There may even be implementations who do that, and tha I am not aware of. Would you dismiss a sound-logic on the basis of there not existing any implementation who does that? If so, how would you account for the existence of web2py? Or the DAL? Do you know of any other implementation of a web-framework that does these controller/model "execution" rather than imports? Did such implementation exist when web2py was made? How about the DAL? If you are saying that a DAL is better, and yet it clearly is an odd-fellow in the web-frameworks eco-system (at least in python, but not just), which most implement an ORM, than how would you account for the justification of having it made? By you logic, that was a mistake, because there were no prior implementations of these patterns... > > >>> Sorry, but I believe it is the other way around. > > We'll see... > >> That all sounds great, but there are some problems. First, it is not how > SQLA works -- from the docs: > As I said, I wasn't sure that this was how SQLA is implemented. I might have gotten that assertion wrong, but that would still have no impact on the soundess of that logic (more on that later) > The problem is, because SQLA doesn't know what records the query will > return, it cannot by default skip the flush, otherwise it may retrieve an > incomplete set. In some situations, you may be able to skip the flush, but > you have to be explicit about that, in which case, you're no longer > benefiting from the automatic behavior of the ORM. This is no different > from the DAL. In any case, you could not turn off automatic flushing in > this particular example because you wouldn't know at the time of the second > query whether or not there are insertions that need to be flushed. > I am not following... What insertions? The ORM is building up an object-graph that represents the insertions/updates, as it goes - even if nothing is returned by those operations. If it doesn't in SQLA, It doesn't mean it couldn't - remember, we are talking about a sequential set of operations, within an atomic transaction - there is nothing that can interfere with this process from outside (if there was, it would no longer be an ACID-compliant system - and that's a whole other story...). The transaction-view on the database-side, is assuming that it will success, and has it's own atomic "semi-replica" of the data being manipulated/added/removed - it it fails at commit-time, it would roll-back the changes, and the object-graph on the ORM side would be dumped anyways... This means that any update/delete/insert operation the the ORM is doing, it is perfectly safe for it to also generate an object-graph representing those changes, assuming that the transaction-commit would not fail, because if it will, these objects would seize to exist anyway... As for the primary-key issue: Correct me if I'm wrong, but how exactly does an "insert" works in web2py? It is getting a new primary-key by that process, right? So the primary-key that is created, is returned by the "insert", right? So what happens in an update? does it not return the primary-key that was modified? If not, I think this could be implemented - using some database-function/trigger thing. If it does not, than at least this would still work in cases that the updating-field also has a unique-constraint, even if it not the primary-key (BRW, you can-not define that in web2py's DAL as of yet - we are setting it in our database manually... This should be included - just a side-note). In that case, since the update operation is updating a uniquely-constrained field, it can assume it would be unique, upon commit, so it can safely treat it as such. How would it know if it's uniquely-constrained? Well, the DAL schema should be able to tell it that - the fact that it currently doesn't is a missing-feature in my view. Anyways, the inference should be sufficiently-relied upon, as given that the constraints are assumed to be defined in the database, than if an update would fail, the entire transaction would fail, and the entire object-graph would be dumpt - so again, it is a safe-assumption to make, given the assumption the the transaction-commit would succeed. > >> No, it could not be disabled without risking conflicts. You can only > disable it when you know you won't have conflicts (i.e., same as in the > DAL), which is not the case in this example. > (for transaction-failures, see above - for primary-key, see below) > >>> Nope, we have 4 -- see above and below. > > We have different premises, obviously we are reaching different conclusions. This is perfectly logical. > >>> Again, not correct. First, in web2py, you are conflating model > definition (i.e., DAL.Table) with data object creation (i.e., DAL.Row). > Only the table definitions happen on each request, and even then, only the > ones you need for that particular request (if you structure your app that > way). > I am not conflating it, since the record-objects may replace some functionality that the schema-objects would have had - at least at some ORMs. In the ORM I am proposing, well, since would be built on-top of web2py's DAL, than obviously it would create extra-objects - even a single-object that an ORM would create in this case, would be considered "more" - that is an unfair comparison. The comparison that is valid, is only against ORMs that do not do that schema-construction up-front - I am not sure hoe SQLA is doing it, so I can not attest to that case - but I am comparing the "total number of objects, that a particular architectural-implementation would generate overall". Ans since most ORMs define the schema using the same classes that would create the record-objects, than in that case wou may say that it generates the entire-schema - but only at the Table-Level (represented by the class-objects), whereas in web2py it would generate all of it - unless you configure it differently, but not by default. Anyways, this is such an overly complex-and circumstantial issue, that I can't see how any of us would be able to know for sure about the memory-footprint - only benchmarks can show that. > As for data objects, web2py creates none in this example, and the ORM > creates one (though it loads the data used to create that object into > memory twice). > Well yes, an ORM as a replacement for the DAL, might create more objects, but that's a trade-off decision - if by doing that it may save itself trips to the database, that it's worth it. Remember, today, memory is cheep. Database round-trips, however, remain the most costly bottleneck in any web framework even today - web frameworks were - and still are - much more I/O bound than CPU/Memory bound. I would gladly pay for a reasonably higher memory footprint, it it gives me much better performance. That said, there are still more/less "wasteful" ways to do that - the "Identity Map" pattern, as it turns out, is also more-efficient memory-wize (compared to Django, for example, which doesn't have it) - but that's a nice bonus-bi-product... > > Fine, but that means this example is moot with regard to why you need an > ORM to begin with, so we need another example. > > As it turns out, it may be so. However, this does not mean that there are no better ones that would shine better for an ORM. > >> Though, unfortunately, it doesn't even have the other capabilities you > claim. > > Well, it doesn't in SQLA, as it turns out, yes. But it would, in my suggested logic. > >> Seems like the opposite as far as I can tell. > > Efficient and faster, assuming my proposed-logic is implemented - not using SQLA with this example (apparently). Again, the issue is the premises... > > That means it doesn't cache queries in the sense that you think it does > (i.e., if you issue the same query, or a query that retrieves some of the > same records, it does another database hit -- it does not first look for > the records in the session). > SQLA apparently does not - as you pointed out. But my proposed-logic would. > No, even with auto-flushing turned off it does the select query twice. > Turning off flushing prevents updates but does not obviate the need for a > select -- these are two separate issues. > Yes, I've acknowledged that already now. But it would be the case in my suggested logic. > > Again, see above. It still does the query. *After* the query completes, > it will recognize that the record pulled from the database is the same as > the one stored in the session, so it will not create a new copy -- but that > doesn't eliminate the select query. > (see above) Less efficient in this case and in lots of cases because of the overhead of > managing the session. Perhaps this is balanced by other cases where it is > more efficient, but we need to see what those other cases are. > > in this case, you are right. But assuming my proposed logic, this ORM would issue less database-operations, so it would be more efficient. Not memory-wize, perhaps but again, that may be circumstantial, and in any case a well-worth investment if less database-round trips are made. > In short, I think you need to look a little more closely at how SQLA > really works, as it does not appear to do what you think it does. And note > that it is not a useful response to simply say that we should imagine an > ORM that does exactly what you wish, even if there is currently no ORM in > existence that does those things. > (see above: context - web2py/DAL implementations were first-to-market also) > Your argument here has been that we need an ORM on top of the DAL because > ORM's by their nature enable additional functionality -- if you can't point > to a single ORM that actually has such functionality, though, it's hard to > argue that such functionality is an essential benefit of the ORM pattern, > or more generally, that it couldn't simply be implemented in a DAL. > Yes. Hard to argue. But I'm still trying...:) -- --- 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.
