Is there a common data interface for RavenDB? For example, how could Java, Python, or even PHP interact with RavenDB?
In RavenDB 3.0 they added a Java client as well. I haven't tried it myself, but you can read about it here:
http://ayende.com/blog/168354/what-is-new-in-ravendb-3-0-jvm-client-api
In that blog post Ayende also mentions:
RavenDB has always been accessible from other platforms. We have users using RavenDB from Python and Node.JS, we also have users using Ruby & PHP, although there isn’t a publicly available resource for that.
With RavenDB 3.0, we release an official Java Client API for RavenDB. Using it is pretty simple if you are familiar with the RavenDB API or the Hibernate API.
So to answer your question: No, there isn't a "common data interface" for everything, but most things are certainly doable.
Almost every ravendb command is available through HTTP via REST.
For version 2.5 it is documented http://ravendb.net/docs/article-page/2.5/csharp/http-api/http-api-single. For version 3 they ommitted that documentation (or it is not available yet), but it is still there.
The client (.net or java) is 'just' a wrapper around those HTTP REST calls that does things like caching, serializing, failover, etc..., to make it much easier to work with RavenDB in your application.
Related
I want to use Azure DocumentDb in my ASP.NET 5 project and it seems that DocumentDb .NET SDK doesn't work with DNX yet. Is it so? And if Yes maybe there is a workaround here?
You can get ASP.NET 5 to target the full .NET Framework as opposed to Core. The biggest advantage of targeting Core is that it would allow you to run outside of Windows, but if this is not a requirement for you then the full framework should be fine.
I don't know the status of work on supporting DNX, but assuming that's not going to come in time, I can think of several ways to work around it:
Hit the DocumentDB REST API directly
Run edge.js in process inside .NET and use the node.js SDK although there seems to be some question about what platforms are supported by edge.js.
Use node.js instead of .NET. My experience helping .NET developers ramp up on DocumentDB has convinced me that the JavaScript-centric design of DocumentDB means, it's much easier to use from node.js than it is from .NET, IMHO. Many of the .NET problems come from the difference between strongly typed .NET and highly dynamic JavaScript. Stored procedures are written in JavaScript not .NET.
I just discovered this Language and I'd like to know if it's possible to make basic CRUD web app using a database.
There are libraries for mysql and postgresql, and the core library provides a web server with HTTP, HTTPS and WebSocket support.
There is a templating library which isn't part of the official release. And, there is also a community mustache port (I don't think it builds at the moment, so you may need to fix it).
So it's definitely possible. But you'll be an early adopter. If you want to get stuff done quick, I'd choose something else, but if you're wanting to learn new skills, dive in.
Sure. It's a pretty new language though so you aren't going to find the robust library support you will in other languages just yet. It's rapidly growing however so I don't think it will be long. You can either write your server in dart or write your server in another language and expose a basic HTTP interface for your Dart client to consume.
Here is an example of writing a simple web application which creates and stores "blog" posts. Both the client and server are written in Dart. The database is MongoDB.
Also check out this question for more information.
Can anyone provide a suggestion on the best way to use Exchange Services 2007 in a Mac application using Cocoa? I need to access Inbox mail messages and their headers to parse the information I need.
I have written an implementation in my .NET application, but of course .NET provides some nice libraries to handle all the complex types and such.
Thanks in advance.
Cocoa doesn't really have any decent SOAP libraries available that I'm aware of. You could either try to access Exchange via IMAP if it's enabled for your server (e.g. with MailCore) or embed another language with better SOAP support (e.g. Java, Python). Here's an example of using Java/JAXWS to talk to EWS.
Microsoft has an EWS Java API but it was apparently so poor-quality that they pulled it. However, there's a link to the download on that page if you want to try it anyway, and it's open source so you could potentially fix any bugs you ran into.
Doc,
I came across this EWS OSX Widget in my search for the same thing. It would be good to know if this works for you.
http://ewsmacwidget.codeplex.com/releases/view/16559
I know SysCache uses ASP caching under the hood, but since I'm not aware of the implementation of the ASP cache (and if it depends on anything IIS), I was wondering if SysCache would work in a non-web application (like a Windows Service)?
Activating it and using NHprofiler seems to show it is not.
No it doesn't, Syscache is an abstraction over asp.net cache. You have to use a different cache for the service.
EDIT:
I remember this blog post: http://www.hanselman.com/blog/UsingTheASPNETCacheOutsideOfASPNET.aspx
They say it should be usable outside a web-environment. It's just not recommended because microsoft maintains it to be usable in a web environment. That means that you can use it now, but you might have trouble when .Net 4 (or 5, 6, 7, ...) is released.
There seems to be a number of options for interfacing to Documentum; WDK, DMCL, DFC, DFS, DQL, etc.
What else is there?
When whould you use which interface? For .NET developers, for Java developers?
WDK is for making websites.
DMCL is an old api for communicating with Documentum, in last versions it's only present as an emulation layer, so it should be avoided.
DFC is the preferred API to interact with Documentum, provides all functionality.
DFS is for using Documentum from webservices.
DQL is for querying, it's SQL-like.
DFC and WDK are Java, the others are probably usable from .Net
David provides a good overview but to expand a bit...
DFC is the base Java api for interacting with Documentum. WDK is actually built on top of DFC. The DMCL is the legacy api built in C(or C++ I'm not 100% sure). Prior to D6, all DFC calls used the DMCL under the covers but that layer was rewritten in java for D6 and the DMCL is there just to provide backwards compatibility at this point.
As for accessing Documentum via .NET there is a Documentum PIA that you can use to access the DFC libraries from a .Net project rather than using the traditional Java route.
You could also consider using the CMIS (Content Management Interoperability Services) interface that's being developed for Documentum. It's a web service interface that expands upon AtomPub. It won't be able to leverage all the bells and whistles of the Documentum platform, but it should allow you to use other backends like Alfresco and SharePoint. There's an Early Access Release available via EMC for Documentum.
Massive operation, like bulk upload, you must use DFC, because some feature are accesible only via DFC.
Web operation, I suggest the use of DFS, with is own caching system (can be a problem) and session manager.
The code is more decoupled using DFS instead using of DFC.
DFC use is deprecated, but at the moment you cannot have the same result using DFS.
There is also some technical difference: for example DFC is RMI shared object, so the object is connect to the content server. Instead DFS after web service give you the object, the object is disconnect from content server.
In DFC you have to manage Session, connection, and so many other things tipical of RMI.
DQL is only a way to make query, and so other basic operation on Documentum.
Both David and shsteimer is right.
But Documentum PIA for .Net is not encouraged now because it will be deprecated in future edition of Documentum.
I just found this old discussion, but based on the following link, the "EMC Documentum REST Services" is something to consider:
https://community.emc.com/community/edn/documentum/blog/2013/06/22/announcing-emc-documentum-rest-services-70