In my Grails application, I run some batch processes asynchronously, and would like the process to log various status messages so that the administrator later can examine them.
I thought of using log4j JDBC appender as the simplest solution, but from what I can tell it doesn't use DataSource. Has anybody gotten it to work or wrote their own Grails DB Appender?
Did anybody have a similar requirement, and how did you implement it?
I can create a notion of Job, which hasMany LoggingMessages, but thought perhaps there is a standard way or a plugin that does this.
P.S. There was a somewhat related discussion a few weeks ago, but that one was about a different aspect than what I need.
http://grails.1312388.n4.nabble.com/Async-Event-that-publishes-progress-td2303653.html
Someone seems to have written a version of the log4j JDBC appender that does use a datasource and adds some other nice features. Have a look at this blog entry by the author.
If you want to consider stand alone log server, I'd recommend this tool. It would accept log data over sockets and persist them. Works with many database brands too. Very simple to set up. It's not a free tool though...
Related
After a bunch of googling, I don't really see a good way to have Orleans work with an existing Relation-Database backend.
Every example that I have found for doing this relies on adding columns to deal with concurrency and I haven't really seen any samples of how to use Orleans with, as is the typical example, the northwind database or something.
This leads me to believe that Orleans is not really intended to be used in this way (because if it was I would expect someone somewhere to have create a sample app demonstrating it by now). Am I missing something? Has anyone seen a sample project or blog post explaining how to use, say, an existing EF context with Orleans? This needs to be done without adding additional columns. I am working with data that is controlled by multiple teams in a mission critical system, so there is no way I will get approval to start adding columns to hundreds of tables.
As #Milney says, to my knowledge, there is nothing special in Orleans that would prevent you from using a normal EF DbContext, no extra columns required.
If, on the other hand, your issue is that other applications are causing concurrency issues from outside Orleans, then I think you'll need to deal with them as you would in any application (e.g. with optimistic concurrency checks).
But it's possible I'm misunderstanding your use case.
Does anyone know if there is a definitive best practices guide for GORM? I find information scattered across different blogs and different resources, but I can't find a definitive guide. I find stuff that says to not do database related stuff in controllers and to keep those things in the service layer, for example. However, it'd just be nice to se what the suggested approach for writing a simple web app is. Should we always use command objects in controllers and pass those command objects to services? Should we store those command objects in session rather than storing actual domain objects in session, which seems to cause a lot of lazy init exceptions, etc.?
I've tried to piece together the information that I've found, but if anyone knows of a comprehensive resource, that would be great.
There is some great information available from the GORM Gotchas series. It's in three parts.
GORM Gotchas (Part 1)
GORM Gotchas (Part 2)
GORM Gotchas (Part 3)
To answer your specific questions about Services and Command objects.
Q: "Should we always use command objects and Services?"
A: Some would argue that it's overkill to do so, however I personally think it's a great pattern and makes things much easier to test and extend. It may seem like a lot of effort but it does pay off in large projects.
Q: "Should we store command objects in session rather than domain objects?"
A: Store as little in the session as possible (if at all). If you have to store something there it's best that it be small and light weight. Command objects (typically) are going to be better for this than a Domain class.
Update (11/19/2014)
I'd like to highlight a very good series that outlines a lot of the potential issues faced using GORM and Hibernate. It's very long, but worth reading if you plan on using GORM/Hibernate in a large scale multi-user project. Don't be turned away by the negative approach because it does contain a lot of useful information.
I don't like Hibernate (and Grails), PART 1
I don't like Hibernate/Grails, part 2, repeatable finder problem: trust in nothing!
I don't like Grails/Hibernate part 3. DuplicateKeyException: Catch it if you can.
I don't like Grails/Hibernate, part 4. Hibernate proxy objects.
I don't like Hibernate/Grails part 5: auto-saving and auto-flushing
I don't like Hibernate/Grails part 6, how to save objects using refresh()
I don't like Hibernate/Grails part 7: working on more complex project
I don't like Hibernate/Grails, part 8, but some like Hibernate and Grails. Why?
I don't like Hibernate/Grails part 9: Testable code
I don't like Hibernate/Grails part 10: Repeatable finder, lessons learned
I don't like Hibernate/Grails part 11. Final thoughts.
The book Grails in Action talks a lot about best practices in Grails. At the time of this writing it isn't published in its final form, but you can buy and read the preview.
I was recently looking for the same answers you are asking and that book has helped me a lot.
I am quite new to Rails and I need to implement a project for my University. This project consists of a website that will use a binary file as database.
So I need to know a thread safe way to read and write this file, taking into consideration that the same file (database) will be used by multiple process (each time someone access the site, it should read and write data into the file).
Thanks in advance
There really isn't a graceful way to handle that. You're much better off taking a more traditional approach, with a SQL server like mySQL or PostgreSQL, which do basically that same thing.
Edit:
I didn't realize you could use sqlite in multi-threaded mode. That would seem to satisfy both requirements...
How does grails handle dynamic class reloading ?
I did a little digging around, now this may not be perfect and will not include all the little details, however at a broad level I think this is what goes on:
A thread is run say every X seconds, this thread detects if there have been any changes to Grails artifacts (domain,service,controller), custom artifacts can be included.
If an artifact has been changed, then this bit of code is run which I think does the magic:
GroovyClassLoader gcl = new GroovyClassLoader(application.getClassLoader());
initialisePlugin(gcl.parseClass(DefaultGroovyMethods.getText(conn.getInputStream())));
I got this by looking around DefaultGrailsPlugin which is part of grails core.
Everything in Grails is treated as a plugin even the service,domain,controllers and so on.
With a custom ClassLoader. Probably to vague a question and requires too in-depth of an answer for a site like SO. Might be better suited for the Grails mailing list.
I'm developing an app (basically an intranet) which has a few small sets of users, each a company using the app internally.
Up to now, each set of users has its own deployment with a separate domain name and database, but all living on the same server. This means that each time I have to push an upgrade I need to deploy once per client. Also, each new client means adding a new deploy target, for which I'm currently using Capistrano's multistage plugin, but it's getting a bit ridiculous.
This is a less than ideal setup, so after some thought I came up with the idea of modifying the app so that it handles multiple domains, each mapped to a different database, but on a single deployment. I created a small proof-of-concept app which basically has a before_filter in ApplicationController acting as a multiplexer for domains/databases, connecting ActiveRecord to each domain's database on each request. This worked really well, but I haven't applied this to the big app yet and I can think of at least one problem down the road: running migrations across all databases. I'm pretty sure I can work around that one though, maybe I'll tweak the rake task a little, but I'm worried that might not be the last of problems with it.
Has anyone ever tried this, or can think of any major reasons why this would be a bad idea? I would like to listen to some opinions.
Thanks!
This is usually called multi-tenancy. Here is a presentation or video about doing it in rails. Couldn't tell if it was any good, it was blocked here at work.
And no, there is nothing wrong with it as an idea. I'm not sure about your particular implementation, but I have worked on apps that were multi-tenant in the past and can't say we ever had much difficulty except when trouble clients wanted to stay on a legacy version of the product and we wanted to move forward.
I have a similar app and still the same problem as you, and after many tries, i ended up (before a desirable core solution came) with one env file per domain and kind a filter like yours.
I've been running in production for almost 1 year, and the only problem i detected is that rails expected the main db (even you won't use it) to have the same migration level as the others. (this problem arise under certain conditions)
If you need futher details, just let me know.
I hope this helps.