How Function and Virtual methods are different in IBM ODM?
When we go for Functions and when we go for Virtual Method?
I would suggest to go as much as you can with Java mapping as it will be easier to debug when there is a probleme.
Use B2X virtual methods only in very specific cases, like the ones when you need to get an internal parameter like the engine (context).
Best
Emmanuel
Related
What is the proper way of using domain module in NodeJS applications?
Wrap up the code blocks with the domain instance like how we use try-catch blocks? If yes, should we create new instances of domain each time for each separated block?
Wrap up the main function with the domain run method? If yes, is that really sufficient for an enterprise application for example?
P.S. Is there any well-known open-source node project with an extensive use of domain module where I can study their code?
P.P.S. Looking at the node documentation and tutorials, I see that almost all of them just simply wrapped up the main function within the domain's run method, however as far as I can see they are mostly copying each other. I basically can't see how people use domain module in different situations (what I see is mostly a copy of node documentation with couple of minor changes)
I'm using AzureDirectory and Lucene .NET 2.9.4 but I have wo problems:
searcher doesn't seems to be so fast. I'm indexing with these settings:
indexWriter.SetUseCompoundFile(false);
indexWriter.SetMergeFactor(1000);
index is around 3.5gb and it has 12.126.436 docs.
To create the indexSearcher it takes around 5 min or more even if index is already on local disk. Is the index too big? I tried to perform a single term search using MultiFieldQueryParser on two fields. TermVector on fields is off
Everywhere is suggested to create only an instance of indexSearcher and share it between queries (in fact it is slow to be created) but I don't know how to share the Searcher singleton (it is the class that perform the search) between various web requests. If I create the singleton on the webrole class, then how can I use that instance to perform the search? At this moment every web requests recreates the singleton.
Thanks a lot
I have actually used that exact version of Lucene.NET with AzureDirectory and it doesn't work well. AzureDirectory in my opinion is not written for production scale.
If you look at the source code for AzureDirectory, it is using:
older version of Lucene as a base (2.3x)
exceptions are thrown everywhere (hard to debug/catch the right ones in production)
it uses the old storage API (pre 1.8 version of the SDK)
I ended up creating my own dedicated Virtual Machine and using the .net 3.0.3 Lucene.Net library. Works like a champ in that environment, since I do not need to implement AzureDirectory.
You should have only ONE IndexWriter that is easy to implement with a storage queue. You can have multiple IndexReaders if you want to limit them write a IndexReader pool (like a SQL connection pool). I have multiple of those run fine with no exceptions flying around like they where with AzureDirectory.
My environment is a bit different lots of smaller indexes....not one massive one.
Maybe this is the AzureDirectory that people are talking about, maybe not - I tweaked this in order to get better performance. While I won't claim that it's production-grade and rock solid, it may help you over the AzureDirectory that you are currently using.
Hope it helps,
I believe that the mvc mini profiler is a bit of a 'God-send'
I have incorporated it in a new MVC project which is targeting the Azure platform.
My question is - how to handle profiling across server (role instance) barriers?
Is this is even possible?
I don't understand why you would need to profile these apps any differently. You want to profile how your app behaves on the production server - go ahead and do it.
A single request will still be executed on a single instance, and you'll get the data from that same instance. If you want to profile services located on a different physical tier as well, that would require different approaches; involving communication through internal endpoints which I'm sure the mini profiler doesn't support out of the box. However, the modification shouldn't be that complicated.
However, would you want to profile physically separated tiers, I would go about it in a different way. Specifically, profile each tier independantly. Because that's how I would go about optimizing it. If you wrap the call to your other tier in a profiler statement, you can see where the problem lies and still be able to solve it.
By default the mvc-mini-profiler stores and delivers its results using HttpRuntime.Cache. This is going to cause some problems in a multi-instance environment.
If you are using multiple instances, then some ways you might be able to make this work are:
to change the Http Cache to an AppFabric Cache implementation (or some MemCached implementation)
to use an alternative Storage strategy for your profile results (the code includes SqlServerStorage as an example?)
Obviously, whichever strategy you choose will require more time/resources than just the single instance implementation.
I have a Java\Spring\Hibernate application - complete with domain classes which are basically Hibernate POJOs
There is a piece of functionality that I think can be written well in Grails.
I wish to reuse the domain classes that I have created in the main Java app
What is the best way to do so ?
Should I write new domain classes extending the Java classes ? this sounds tacky
Or Can I 'generate' controllers off the Java domain classes ?
What are the best practices around reusing Java domain objects in Grails\Groovy
I am sure there must be others writing some pieces in grails\groovy
If you know about a tutorial which talks about such an integration- that would be awesome !!!
PS: I am quite a newbie in grails-groovy so may be missing the obvious. Thanks !!!
Knowing just how well Groovy and Grails excel at integrating with existing Java code, I think I might be a bit more optimistic than Michael about your options.
First thing is that you're already using Spring and Hibernate, and since your domain classes are already POJOs they should be easy to integrate with. Any Spring beans you might have can be specified in an XML file as usual (in grails-app/conf/spring/resources.xml) or much more simply using the Spring bean builder feature of Grails. They can then be accessed by name in any controller, view, service, etc. and worked with as usual.
Here are the options, as I see them, for integrating your domain classes and database schema:
Bypass GORM and load/save your domain objects exactly as you're already doing.
Grails doesn't force you to use GORM, so this should be quite straightforward: create a .jar of your Java code (if you haven't already) and drop it into the Grails app's lib directory. If your Java project is Mavenized, it's even easier: Grails 1.1 works with Maven, so you can create a pom.xml for your Grails app and add your Java project as a dependency as you would in any other (Java) project.
Either way you'll be able to import your classes (and any supporting classes) and proceed as usual. Because of Groovy's tight integration with Java, you'll be able to create objects, load them from the database, modify them, save them, validate them etc. exactly as you would in your Java project. You won't get all the conveniences of GORM this way, but you would have the advantage of working with your objects in a way that already makes sense to you (except maybe with a bit less code thanks to Groovy). You could always try this option first to get something working, then consider one of the other options later if it seems to make sense at that time.
One tip if you do try this option: abstract the actual persistence code into a Grails service (StorageService perhaps) and have your controllers call methods on it rather than handling persistence directly. This way you could replace that service with something else down the road if needed, and as long as you maintain the same interface your controllers won't be affected.
Create new Grails domain classes as subclasses of your existing Java classes.
This could be pretty straightforward if your classes are already written as proper beans, i.e. with getter/setter methods for all their properties. Grails will see these inherited properties as it would if they were written in the simpler Groovy style. You'll be able to specify how to validate each property, using either simple validation checks (not null, not blank, etc.) or with closures that do more complicated things, perhaps calling existing methods in their POJO superclasses.
You'll almost certainly need to tweak the mappings via the GORM mapping DSL to fit the realities of your existing database schema. Relationships would be where it might get tricky. For example, you might have some other solution where GORM expects a join table, though there may even be a way to work around differences such as these. I'd suggest learning as much as you can about GORM and its mapping DSL and then experiment with a few of your classes to see if this is a viable option.
Have Grails use your existing POJOs and Hibernate mappings directly.
I haven't tried this myself, but according to Grails's Hibernate Integration page this is supposed to be possible: "Grails also allows you to write your domain model in Java or re-use an existing domain model that has been mapped using Hibernate. All you have to do is place the necessary 'hibernate.cfg.xml' file and corresponding mappings files in the '%PROJECT_HOME%/grails-app/conf/hibernate' directory. You will still be able to call all of the dynamic persistent and query methods allowed in GORM!"
Googling "gorm legacy" turns up a number of helpful discussions and examples, for example this blog post by Glen Smith (co-author of the soon-to-be-released Grails in Action) where he shows a Hibernate mapping file used to integrate with "the legacy DB from Hell". Grails in Action has a chapter titled "Advanced GORM Kungfu" which promises a detailed discussion of this topic. I have a pre-release PDF of the book, and while I haven't gotten to that chapter yet, what I've read so far is very good, and the book covers many topics that aren't adequately discussed in other Grails books.
Sorry I can't offer any personal experience on this last option, but it does sound doable (and quite promising). Whichever option you choose, let us know how it turns out!
Do you really want/need to use Grails rather than just Groovy?
Grails really isn't something you can use to add a part to an existing web app. The whole "convention over configuration" approach means that you pretty much have to play by Grails' rules, otherwise there is no point in using it. And one of those rules is that domain objects are Groovy classes that are heavily "enhanced" by the Grails runtime.
It might be possible to have them extend existing Java classes, but I wouldn't bet on it - and all the Spring and Hibernate parts of your existing app would have to be discarded, or at least you'd have to spend a lot of effort to make them work in Grails. You'll be fighting the framework rather than profiting from it.
IMO you have two options:
Rewrite your app from scratch in Grails while reusing as much of the existing code as possible.
Keep your app as it is and add new stuff in Groovy, without using Grails.
The latter is probably better in your situation. Grails is meant to create new web apps very quickly, that's where it shines. Adding stuff to an existing app just isn't what it was made for.
EDIT:
Concerning the clarification in the comments: if you're planning to write basically a data entry/maintenance frontend for data used by another app and have the DB as the only communication channel between them, that might actually work quite well with Grails; it can certainly be configured to use an existing DB schema rather than creating its own from the domain classes (though the latter is less work).
This post provides some suggestions for using grails for wrapping existing Java classes in a web framework.
I want to to intercept a method in Service Builder, for example: XXXLocalService.update(). But I don't know the correct way to do this. I have done some research but I haven't found a clear way to do this.
Any help will be greatly appreciated.
There are basically two ways to achieve this in Liferay, assuming you want to intercept Liferay's services:
Service Wrapper Hooks
What this does is gives you a wrapper around the desired service, for eg: UserLocalServiceWrapper would be a wrapper around UserLocalService and would have complete control over the methods defined in this interface. And this is a good approach if you know the exact method you want to modify/intercept in that particular service.
Also with this approach you have full control whether the original method should run or not.
The link provides the full detailed tutorial how to achieve this.
Model Listener Hooks
This hook should be used when you want to track any changes on the particular Model like in the above case User and this is helpful when you are not sure which method is going to update the model.
What this basically does is gives you a set of methods like onBeforeUpdate, onAfterUpdate, onAfterCreate etc to have control over the model.
Also this approach would work good enough for your custom services as well.