31–40 of 42 posts
Earlier quoted context omitted.
Yes, but they don't parameterize the sort order on every sortable table, or the limits used in pagination, or the custom join expressions ORM developers inevitably write.
I am quite sure Django's ORM (the one I use every day) would properly protect limits and pagination.
Earlier quoted context omitted.
That's nice. Until you forget to quote_name a dynamically selected table name.
Why would you want to name a table dynamically?
But, to be clear, you don't often create tables with dynamic names (though you will sometimes; for instance, to repeatedly load huge datasets, which comes up in time-series apps)... but you very often need to select which table to use at runtime based on user inputs. Again, in real-world apps.
For what it's worth, I believe the same quote_name() mistake pops up with column names too. But you probably don't dynamically select those based on inputs either.
Can anyone give me a technical reason to deploy on a IIS and ASP platform instead of Apache/Nginx and one of the dozens of open source solutions for deploying a web application? From where I'm sitting, it seems to me the reasoning is "I drank the Microsoft Kool-Aid". Surely there's a better reason than that.
Is this a real question or a silly jab at Microsoft? I think you're underestimating the number of existing businesses who have .NET at their core, in which case the question is what justifies moving off of .NET? In my experience .NET can be - while not as hip - a very solid framework.
>I think you're underestimating the number of existing businesses who have .NET at their core, in which case the question is what justifies moving off of .NET? In my experience .NET can be - while not as hip - a very solid framework.
I wanted to know why you'd deploy on that platform initially. Of course if you're already fucking using it, you're probably not going to switch.
Can anyone give me a technical reason to deploy on a IIS and ASP platform instead of Apache/Nginx and one of the dozens of open source solutions for deploying a web application? From where I'm sitting, it seems to me the reasoning is "I drank the Microsoft Kool-Aid". Surely there's a better reason than that.
You use IIS because you want to use ASP. You can't replace ASP with Nginx, it's an entire development stack, not just a webserver. And I actually like ASP. It's fast, easy to develop with, easy to deploy and there's great library support.
Can anyone give me a technical reason to deploy on a IIS and ASP platform instead of Apache/Nginx and one of the dozens of open source solutions for deploying a web application? From where I'm sitting, it seems to me the reasoning is "I drank the Microsoft Kool-Aid". Surely there's a better reason than that.
If you're deploying an app in to an enterprise that is already running an AD environment with other Microsoft products like SharePoint, Exchange, Office, and Microsoft Dynamics, it makes a lot of sense. I'm a Mac user and our startup is a kool-aid drinkin' Ruby on Rails shop, but I have administered enough large networks to see the power and value of Microsoft in the enterprise. Like it or not, the integration betwee…
Can anyone give me a technical reason to deploy on a IIS and ASP platform instead of Apache/Nginx and one of the dozens of open source solutions for deploying a web application? From where I'm sitting, it seems to me the reasoning is "I drank the Microsoft Kool-Aid". Surely there's a better reason than that.
ASP.NET is an extremely full-featured, well-tested, and carefully designed enterprise web stack. What you're really asking is, why would you deploy on an enterprise stack as opposed to a modern app framework. There's lots of reasons, none of which will be congenial to you: * A much larger pool of available developers * Better enterprise integration features (depending on your platform, J2EE or ASP.NET may be predeter…
I've never hired anyone, so I wouldn't know. Is the pool of MS devs really that much bigger than, say, your PHP users?
Earlier quoted context omitted.
Why would you want to name a table dynamically?
Thanks for helping make my point about real-world dev vs. on-paper dev. But, to be clear, you don't often create tables with dynamic names (though you will sometimes; for instance, to repeatedly load huge datasets, which comes up in time-series apps)... but you very often need to select which table to use at runtime based on user inputs. Again, in real-world apps. For what it's worth, I believe the same quote_name()…
Earlier quoted context omitted.
Why would you want to name a table dynamically?
Thanks for helping make my point about real-world dev vs. on-paper dev. But, to be clear, you don't often create tables with dynamic names (though you will sometimes; for instance, to repeatedly load huge datasets, which comes up in time-series apps)... but you very often need to select which table to use at runtime based on user inputs. Again, in real-world apps. For what it's worth, I believe the same quote_name()…
ORMs are there to shield you from database details. I don't care whether the underlying database is a MySQL instance running on Amazon's cloud, an Oracle RAC down our datacenter or even a non-relational animal we use for very high volume operations. I don't care if the data is in tables or a tree. The kind of stunt you are trying to convince us is reasonable should never be done on top of the ORM, but under it, or, better, by its side. If you have a humongous dataset to load, don't do it through the ORM - do it directly on the datastore.
On a side note, I find your tendency to rely on name-calling and insinuations most disturbing and quite inappropriate for a place like HN.
Earlier quoted context omitted.
Thanks for helping make my point about real-world dev vs. on-paper dev. But, to be clear, you don't often create tables with dynamic names (though you will sometimes; for instance, to repeatedly load huge datasets, which comes up in time-series apps)... but you very often need to select which table to use at runtime based on user inputs. Again, in real-world apps. For what it's worth, I believe the same quote_name()…
I most certainly won't create tables named after web input. ORMs are there to shield you from database details. I don't care whether the underlying database is a MySQL instance running on Amazon's cloud, an Oracle RAC down our datacenter or even a non-relational animal we use for very high volume operations. I don't care if the data is in tables or a tree. The kind of stunt you are trying to convince us is reasonable…
The apps that I've seen do best against SQLI had an enforced policy that front-end devs couldn't write queries, that their access to the database was restricted through stored procedures, and that access was further restricted with database permissions. Stored procedures aren't a panacea either, but they're definitely more reliable than the Django ORM.