I am a complete noob when it comes to grails (and still very noobish when it comes to groovy) so I apologise if this is a dumb question.
I am building a simple web app and I want to control portions of the domain in my app based on file system objects (i.e. directory structure and file type) rather than database data. How easy is it to do this or are the domain objects so entwined with GORM that it is not worth the effort to try?
I ran into this question myself a couple of weeks ago.
You can just add the following snippet to the Domain Class.
def isAttached()
{
return false
}
Now it isn't connected to your database. Voila!
You can also use:
class YourDomainClass {
static mapWith = "none" // disable persistence for this domain class
See grails documentation and this answer. Appears to have been added in Grails 2.0.1 but not documented until version 2.3.0.
There is no built-in way to map domain classes to file system objects as you've described, but equally there is no requirement that your domain classes map to a relational database. The subject of how to create a Grails app that doesn't use a relational database is addressed
here and here (and possibly elsewhere).
A couple of ways to do this.
First, you can declare your properties that map to file system data as transient, and go to file system when getters / setters are called (you have to override them). You can also load them using onLoad if you need them to be in memory always.
Second - Hibernate handles the persistence. Hibernate allows for you to define your own user type, which can handle the persistence whichever way you want. This way it might happen for you more transparently (though you'd have to make sure you understand hibernate fairly well, to make sure there aren't any side effects, I am not sure).
http://i-proving.com/space/Technologies/Hibernate/User+Types+in+Hibernate
Related
How can I enforce that all entity persistence operations in my Grails application happen via GORM data services, and never directly on my domain classes (e.g. the methods in GormEntityApi and dynamic finders)?
Ideally the GormEntityApi and dynamic finder methods would not be available on my domain classes at all, but I'd also accept a solution that neuters the methods by causing them all to throw e.g. an UnsupportedOperationException.
I've done a bunch of internet searches, pored over the GORM documentation, and even dug around in the GORM code a bit, and I can't seem to find any information about this. Since data services provide all the same CRUD functionality as GormEntityApi and dynamic finders, this seems like a reasonable thing to want to do. I feel like I must be missing something.
How can I enforce that all entity persistence operations in my Grails
application happen via a GORM data services
There is no way to enforce that right now.
I've done a bunch of internet searches, pored over the GORM
documentation, and even dug around in the GORM code a bit, and I can't
seem to find any information about this.
We don't have support in the framework for doing that.
Since data services provide all the same CRUD functionality as
GormEntityApi and dynamic finders, this seems like a reasonable thing
to want to do. I feel like I must be missing something.
I don't think you are missing something. We have considered not adding the GormEntity trait to domain classes by default, but right now that happens and we don't provide a mechanism for turning that off.
I have to identify all domain classes which are not used in my grails application the project has approximately 300+ domain classes, is there any(plugin) way to identify the domain which are currently not used
There isn't any plugin or tool that will do this for you. It's going to be up to you to determine if a domain class is used. Some ways to approach this would be:
Does it exist persisted in your data store? If not, it may not be used.
Remove it from the system. Do all the tests pass?
Aside from auditing the code (searching for domain classes by name) there isn't going to be a definitive way to determine this.
I'd like to make my usage of open-dolphin in grails sever as easy as possible. So, I'm looking for way to handle CRUD actions on domain classes(on the server side) automaticaly. In demos from open-dolphin project I havent found any idea how to achieve this(if I missed something, please point me where I should study). Instances are pulled from server on request and until it would be pulled/updated again there is no way to recognize changes that happen on server(I've been investigating mainly crudDemo in open-dolphin project).
Since CRUD actions can come not only from user via web or remote client, but also as consequence of other actions, cascade deletes, from services etc.(changes made to the database via sql, are probably untreatable), I thing that handle actions in classes controllers is not enough.
I came up with idea of handling CRUD actions using GORM events, with those I can keep dolphin models persistent with database, check PMs before update or delete, and probably handle all changes on domain classes instances that grails is doing. But, I have to write very similar logic to each class, be sure I havent missed any event on any class(scaffolding may help) and there are probably other consequences that I do not realize now..
So my question is: Is there any documentation, pattern, plugin, open-source code, etc., where open-dolphin is implemented into grails that way, that it autamaticaly propagates CRUD actions on domain classes instances to its presentation models? Or anything that aims to achieve this, using scaffolding, observing instances lists and properties, or something else?
Maybe, I misunderstood concept of using open-dolphin with grails, if so, I appreciate any good advice.
Thanks a lot!
for some reason I haven't seen your question before.
You can happily use Grails domain classes and GORM with OpenDolphin on the server side. The "CrudDemo" in OpenDolphin does exactly that.
Here are the domain classes: https://github.com/canoo/open-dolphin/tree/master/dolphin-grails/grails-app/domain/dolphin/grails
Here are the actions: https://github.com/canoo/open-dolphin/tree/master/subprojects/demo-javafx/server/src/main/groovy/org/opendolphin/demo/crud
Note that when we do testing and client and server-side actions run in-memory, there is no grails support available. Therefore, the server-side actions use service interfaces with DTOs instead of Grails domain classes. The implementation as a Grails service then uses Grails domain classes and GORM.
enjoy
Dierk
I recently finished an application using just standard grails way (GORM-domain classes, etc.), but the company is asking me to to include an existing DB from an open source project. Both are just using mySQL DB, which is good, but I'm not sure how to approach this. I've seen some posts regarding grails connecting to multiple DB.
I guess my question is: Is it possible to connect to two databases: one mapped to domain classes and the other not? My primary reason to do this is to keep all the code in one project and reuse code without gutting the project and making a plugin.
Thanks for any insight.
Yes. It is possible - http://grails.org/doc/latest/guide/single.html#multipleDatasources
Whether you map the other database to your domain classes or use it through a service layer is up to your design.
Thanks for the answer. I was also able to find a tool that helps generate the domain class from an existing DB. The tool is called GRAG (Grails Application Generator) which although is not perfect, it is a bit of a help getting me started faster.
I hope this helps others as well.
I'm getting started on a new MVC project where there are some peculiar rules and a little bit of strangeness, and it has me puzzled. Specifically, I have access to a database containing all of my data, but it has to be handled entirely through an external web service. Don't ask me why, I don't understand the reasons. That's just how it is.
So the CRUD will be handled via this API. I'm planning on creating a service layer that will wrap up all the calls, but I'm having trouble wrapping my head around the model... To create my model-based domain objects (customers, orders, so on..) should I:
Create them all manually
Create a dummy database and point an ORM at it
Point an ORM at the existing database but ignore the ORM's persistence in lieu of the API.
I feel like I've got all the information I need to build this out, but I'm getting caught up with the API. Any pointers or advice would be greatly appreciated.
Depending on the scale of what you're doing option 3 is dangerous as you're assuming the database model is the same as that exposed by the external service. Options 1 and 2 aren't IMHO much different from each other - in either case you'll have to decide what your objects, properties and behaviours are going to be - it just boils down to whether you're more comfortable doing it in classes or database tables.
The key thing is to make sure that the external service calls are hidden behind some sort of wrapper. Personally I'd then put a repository on top of that to handle querying the external service wrapper and return domain objects.
In general, ORMs are not known for their ability to generate clean domain model classes. ORMs are known for creating data layers, which you don't appear to need in this case.
You could probably use a code generation tool like T4 to code generate a first pass at your domain model classes, based on either the web service or the database, if that would save you time. Otherwise, you probably would just manually create the domain objects. Even if you code generate a first pass at your domain objects, it's unlikely there is a clean 1-1 mapping to your domain objects from either the database or web service, so you will likely need to spend significant time manually editing your code generated domain classes anyway.