Anyone ever got custom cache dependencies working with NHibernate second level query cache (i.e. using overrides of the .NET CacheDependency)?
I'm pretty sure it is not possible out-of-the-box, but I know that NHibernate is pretty hackable.
The cache region system doesn't really support the flexibility you have when you can instantiate a cache dependency as you put data into the cache.
Here's what the code might look like:
Session.CreateCriteria<Foo>("foo")
.SetCacheable()
.Add(Restriction.Eq("foo.Name", fooName))
.AddCacheDependency(new MyCustomCacheDependency(fooName))
.List<Foo>();
Cache dependencies are handled by the cache providers, not the core.
There are some examples of DB-based expiration in the documentation for the SysCache2 provider.
Related
We have some generic code that operates on the caches in an Infinispan cache container. The code identifies certain caches for which a certain operation has to be performed by a custom property. The cache container and caches are configured through infinspan.xml or the Infinispan subsystem in WildFly.
Previously we would set a custom property on the datastore of the cache. With Infinispan 10+ this is no longer possible. We would have to implement a custom persistence store in order to set arbitrary properties on a cache. This seems like overkill especially since our caches are not persistent.
Is there a way to achieve this from an infinspan.xml, eg. without putting a custom object under a well known key in the cache?
Edit
The previous configuration looked something like this:
<local-cache name="stackoverflow-cache" configuration="default-configuration">
<data-container>
<property name="custom-property-key">custom-property-value</property>
</data-container>
</local-cache>
With version 10 of the Infinispan schema this is no longer supported.
I've made an example of how you can set some custom properties in the configuration here. It isn't trivial...
If you are using Infinispan server, you need a Jar with your classes and put it in server/lib folder.
Let me know if it fits your use case (I hope I didn't misunderstand it).
ps. since you control the parser, you can set your own XML structure if you want.
I noticed that GraphDB, in contrast to RDF4J, does not allow dots in repository IDs. We have versioned repositories containing some taxonomies. The version number is used in repository ID, so for example: taxonomy-0.1.3.
While this works fine in RDF4J, I have to call such a repository differently in GraphDB, e.g. taxonomy-0_1_3. I'd like to be able to use the same set of queries with federation (SERVICE calls referencing the taxonomy repositories) on both RDF4J and GraphDB, so that I could switch between the two based on the use case. In RDF4J, I could work around version numbers by having a federated store with version-less ID pointing to a specific versioned repository. But, as far as I know, GraphDB does not support federated repositories.
Does anyone have an idea how to overcome such a problem? Or are there any plans for supporting less restrictive repository IDs in GraphDB?
Thanks a lot
GraphDB supports SPARQL Federation (or do you mean something else by "federated repositories"?)
I'll post your request as an enhancement task (GDB-5023), but without business context it'll have low priority...
I am using RavenDb across multiple projects and solutions to access three different databases that are all part of the same product. For instance, I have multiple MVC projects that fetch user info and some data out of the 'web' centric database and the 'backend' database, using '-' for the id override (but I need this only for a subset of classes in the 'web' db). And then I have another 'backend' database that is used by services (as well as the MVC projects). And finally a third temp/scratch database I use by another set of services to build the backend db. And of course, all of these are being accessed from different class libraries and even console test, seed, and integration test apps.
Managing all of these is becoming quite a nuisance. Every time I create a new console app or class library that access the db, I have to setup config and raven packages for each project, make sure indexes are built, etc.... Not to mention running update on all nuget updates, or in my case, installing a new unstable version of the server/client binaries.
Is there an easier way to manage this?
I tried to abstract the DocumentStore creation and initialization, as well as index creation into it own project and reference that. But the other projects then had to manually add newtonsoft.json (and nlog) from the package directory.
As well, I am getting the following when I try and abstract the DocumentStore into a class with a static property:
StackTrace of un-disposed document store recorded. Please make sure to dispose any document store in the tests in order to avoid race conditions in tests.
Anyone have any thoughts on handling these issues?
Thanks
I don't think that the manual addition of the references is a big issue, but you can add the actual nuget references as well.
Note that the DocumentStore not disposed error is something that only happened in the unstable (debug builds), and won't happen on release builds.
I'm using the internal glassfish 3.1 plugin for Eclipse, along with a derby database I installed (it shows up on the datasource explorer in the Database Developer view in Eclipse), and I'm fumbling at the "last" step of getting the ORM working so that I can develop an app that persists data with EJBs using Eclipselink for the JPA implementation.
I know I need to configure the persistence.xml file, but I'm at a loss for what needs to be in it, what the individual field names mean. I feel like the purpose of the persistence.xml is to tell Glassfish where to find the database to store everything in, and which JPA implementation to use to do that storing.
I have a bunch of questions.
Do I have to have a persistence entry for each class that represents an object in the database? So if I had a Book class and a Library class, would I need two enteries in persistence.xml or could I just do one case that services them both?
Where can I find more information about how to configure the persistence.xml file IN GENERAL. I have found tons of very specific tutorials with information on how to configure it in X, Y, or Z setting, but nothing that explains the individual bits, and how you'd configure them from a high level.
Once I've setup my persistence.xml file correctly, what else do I need to do to ensure that my #annotated classes are going to be serviced by the ORM implementation correctly? Is there something I need to configure in Glassfish?
I'm not an expert but...
1) Yes, in my experience you need an entry for each class. There could be exceptions to this but I am unfamiliar with them.
2) [http://wiki.eclipse.org/EclipseLink/] is a good place to start.
[http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Configuration/JPA/persistence.xml] has some details that you may already know. I've have trouble finding a perfect resource myself. I've tended to find information fragmented all over the place.
3) In general most of my persistence.xml file has been generated automatically by eclipselink.
After I creating a connection pool and JDBC resource from the glassfish Administration Console
I had to add my
<jta-data-source>jdbc/your_name</jta-data-source>
to persistence.xml.[1]
<property name="eclipselink.ddl-generation" value="create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="database"/>
I added these properties so my identity columns would auto-increment using JPA.
Try these two tutorials to get a better understanding of how it works:
[1] http://programming.manessinger.com/tutorials/an-eclipse-glassfish-java-ee-6-tutorial/#heading_toc_j_24
http://itsolutionsforall.com/index.php
[*apologies I can't post more than 2 links at the moment]
I have an existing NServiceBus 2.6 application that I want to start moving to 3.0. I'm looking for the minimum change upgrade in the first instance. Is this as simple as replace the 2.6 DLLs with the 3.0 Nuget packages or are there other considerations?
For the most part the application migration is quite straight forward, but depending on your configuration and environment, you may need to make the following changes:
The new convention over configuration for endpoints may mean you will need to rename your endpoints to match your queue names (#andreasohlund has a good post about this).
persistence of saga, timeouts, subscriptions etc. now defaults to RavenDb, so if you use SQL Server to persist data, you need to make sure you have to correct profile and endpoint configuration. For SQL Server storage, make sure you add a reference to NServiceBus.NHibernate as it is no longer part of the core.
Error queues are now referenced differently using different configuration ie. use MessageForwardingInCaseOfFaultConfig instead of the regular MsmqTransportConfig error property. You should still be able to use it, but it will look for the MessageForwardingInCaseOfFaultConfig first.
Other than that, I don't think you need to do anything else to get you upgrade working. I modified some of my message definitions to take advantage of the new ICommand and IEvent interfaces as a way communicatinf intent more clearly.
Anyway, I'm sure there will be some cases that are specific to your environment that will require different changes but I hope this helps a bit.