A question of ColdFusion ORM
We are using ColdFusion 9 for the past 6 months and while we've used some of the new features, ORM is something we've avoided because we usually work on the same very large website. Over the years we've used Apache OBJ but then we moved back to CF and used our own DAO objects generated from tables to handle basic CRUD. These objects are basic and need to be regenerated manually for schema changes and do not model table relationships at all. To supplement these we have a set of gateway classes for multi-table queries. While all this is very bespoke, these DAOs and gateways do, however, give us great control over the SQL we execute, for example using locking hints and optimiser hints. Our site is busy but our database is very efficient.
So much for the history lesson: the point of this is that we have a new site upcoming soon that will be written from scratch to handle financial transactions. We would normally use our aforementioned DAO objects to handle CRUD and then the usual set of gateway objects for multi-table joins but I thought we might investigate using baked-in CF ORM...
So with that in mind, I'd love to hear of the lessons, tips and tricks others might have to share in regard to using ORM on a busy financial site. For example:
What's the best way to flush your SQL ? What tips do you have for transactional ORM? How do you setup development and live sites for ORM? What about HQL? When should we just do the SQL ourselves by hand?!
Thanks in advance!
Short answer, YES! go for ORM!!!
What's the best way to flush your SQL ?
ormflush()
What tips do you have for transactional ORM?
<cftransaction> or transaction {} in CFScript works fine, and even work across DSN's, much improved in 9.0.1! watch http://tv.adobe.com/watch/max-2010-develop/coldfusion-undocumented/
How do you setup development and live sites for ORM?
same as without ORM, but you may look into this.ormSettings.dbCreate if u mean the DB creation part
What about HQL?
What about it? :) Use it when u want an array of objects, but nothing stopping you from using the good old <cfquery>
When should we just do the SQL ourselves by hand?!
When you feel like HQL doesn't do what you want.
Check out: Things to watch out for in ColdFusion 9 with CF-ORM however keep in mind that some points are no longer true for 9.0.1
Related
I'm developing a multitenant application using Laravel. I've read different blogs, posts, sites for this and I decided to do it with a single database.
So, I know that I only need to filter every query with the tenant_id and that's it! But if I do it from every query, probably someday there'll be an error and I don't want to cause any information security issue for my tenants.
I read, probably, an old article for it, culttt.com/2014/03/31/multi-tenancy-laravel-4, and I found many concepts that I still don't understand because I'm new to Laravel.
Is this approach still the best for do it? Or has Laravel now its own solution to do it?
I like something similar to this: stackoverflow.com/questions/33219951/php-pdo-add-filter-to-all-queries but from Eloquent. How can I do this?
Thanks.
If I were you I would not go this way. I would create separate database for each client/each app - it's much safer solution and in addition in case you will need create Database backups or restore some client data it will be much simpler to do that than dealing with huge database when you have all your clients.
I have a question about JPA/Hibernate performance.
We are building web application, one of the goals is to store questions and their answers. For both of these things we have class hierarchy, and #Inheritance(strategy = InheritanceType.TABLE_PER_CLASS).
The questions have references to their answers, every question is stored in some list.
I observed using firebug that when I am adding new question to the list and use entityManager.merge I need to wait about one second for response. I think that it is pretty long time to wait for a response for simple add request.
Is it because of the Inheritance strategy, or maybe I shouldn't use entityManager.merge and try to write my own query.
Maybe the performance is low because I am using sql lite database (sql lite is used just for testing, on production postgre will be used)?
Or this kind of performance is pretty standard for ORM solutions.
I use sqlite a lot (sometimes even for production) and the performance is sometimes even better than for traditional client server connections.
Maybe you should debug you application and enable logging of the JPA provider you are using to see if in fact the inheritance model is to blame.
But, if you have done the inheritance correctly then I don't think that would be te issue. It would help if you paste the code for how you declare the classes.
I would also look at a profiler if this persists.
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
I've just started using Zend Framework and Doctrine as its ORM, and I have some doubts regarding the model. It's obvious that the purpose of the ORM is just to map my domain model to database model, but I'm curious how you would model various reports needed on a Web application?
From my point of view, and correct me if I'm wrong, I should avoid writing any queries in the controller (Doctrine Query Language queries, in this case). So, if I want some arbitrary report (e.g. revenue per department, split by month), should I have a special reporting "service" in the domain? This service would fetch my report from the database using ORM queries.
If you could shed some light on this topic, I'd be grateful.
For sure, sometimes DQL is insufficient. In Doctrine2 you can extend it. But Doctrine 1.x is not stupid and you can use native SQL with it: http://www.doctrine-project.org/projects/orm/1.2/docs/manual/native-sql/en
If ORM is insufficient, you can use native SQL. Reporting is the case where SQL queries become tooo complex for ANY simple QL you can image. So... I say go for native queries if you can't avoid it. But save Doctrine for everything else.
Currently we have a project to implement an Internet Banking site, and we are evaluating using Nhibernate on it. ¿Is NHibernate suitable for this kind of application, where performance is important and there will be a large quantity of users doing operations simultaneously?
¿Do you know any successfull stories of using NHibernate in this kind of environment?
I think NHibernate is slow only when is used incorrectly, and I think we can use it with a lot of tweaking, best practices and common sense.
UPDATE: We were contacted for the project not too long ago, and we are still collecting requirements to define the specs. The application its for a small to medium bank in our country, so they expect around a 200 - 300 users as a top simultaneously.
Im pretty sure the DB will be in SQL Server 2005, and will be a n-tier application using webservices to access the data layer.
My team has been using NHibernate in a system requiring high throughput for years without a problem. NH is fairly efficient to begin with, and provides fine-grained control over when and how objects are reconstituted.
With that said, we don't know the specifics of your problem, so we can't make certain predictions. Perform scaling tests before you commit yourself.
NHibernate can be suitable if used correctly.
But, don't pin you down on this answer, since we do not know the correct specs.