the google documentation seems to hint that the app engine go SDK should support using cloudsql, but from this snippet of code, it looks like it's not yet supported.
is there a newer version of the SDK that does allow you to interface with cloudsql?
Cloud SQL works with the latest SDK. The online docs haven't been updated. Pick a MySQL driver of your choosing that can work with appengine/cloudsql package and the databse/sql package will work. Some of the working drivers : mymysql https://github.com/ziutek/mymysql or go-sql-driver : https://github.com/go-sql-driver/mysql
Related
I'm trying to use docusign java launcher, but the documents says that it's compatible with java 11, can I used it with java 8 ?
or can I send Raw request instead ?
This is our minimal supported version. It is possible you can get it working with an earlier version (I heard some folks said they were able to do it), but if you don't - we will ask you to upgrade.
I'm in need of using the BotFramework SDK to build a bridge from Skype to Mattermost. As I understand it, we're pretty much limited to using the BotFramework to accomplish this via their SDK, however C# and Node.js are not really an option for this presently in this case. Is there a way to use Go already with the SDK or does some porting need to be done?
As for January 2020 an implemntation has been provided (not officialy by MS):
https://www.infracloud.io/microsoft-bot-framwework-sdk-for-go/
I'm wondering if anyone has ever tried to use Couchbase Lite (not Couchbase Server) in a Golang application. In other words building it into a Golang binary?
I came across this library Couchbase Lite Core and through a quick read, it looks like the underlying library for Couchbase Lite (I stand corrected)? What I couldn't find though was how to use it.
Has anyone tried to make this work with something like cgo perhaps? I'm looking to build it statically into the application so it doesn't have dependencies when distributed.
Lite Core is the underlying implementation of the upcoming 2.0 version of Couchbase Lite. It's still under development. The intention is to have a common core, with platform and language specific bindings on top.
There is currently no Go implementation I'm aware of. cgo does look like an option. Given the goal of Lite Core being the underlying implementation for all platforms, this seems on its face like a reasonable approach.
If you're interested, there's a GitHub account for community projects at https://github.com/couchbaselabs. If you work on this, it would be great to have it included there.
To see an example of platform integration, take a look at https://github.com/couchbase/couchbase-lite-ios/tree/feature/2.0
I haven't tried embedding Couchbase Lite, but my team and I make extensive use of embedded datastores like BoltDB Assuming you aren't using Couchbase's replication features heavily, BoltDB may meet your requirements.
I have been finding it hard to configure spring session in spring boot. I have seen a lot of implementation using Redis and using gem-fire and H2 JDBC has not resulted in anything productive. Can I use Redis with IntelliJ on my Windows system, because I heard it is not supported on Windows?
It is true that there is no official support for Redis on Windows. From official docs:
There is no official support for Windows builds, but Microsoft develops and maintains a Win-64 port of Redis.
But as mentioned Microsoft has been maintaining it's own version for over a year now, where you can find new releases and well defined steps for setup on Windows.
Tutorials:
There is also a tutorial on how to build Redis using visual studio. You also should look into the JetBrains plugin iedis.
Here is a tutorial for Redis with Spring, also here's an implementation of Spring Session with Redis.
I'm working with the code from google drive in visual studio 2012 (C#). I managed with hours of fiddling around with nuget reference the necessary libraries.
I compiled the test application and got the following warnings:
'Google.Apis.Authentication.OAuth2.DotNetOpenAuth.NativeApplicationClient' is obsolete: 'NativeApplicationClient is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for WindowsStore apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Authentication.OAuth2.GoogleAuthenticationServer' is obsolete: 'GoogleAuthenticationServer is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for Windows Store apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Drive.v2.DriveService.Scopes' is obsolete: 'Use DriveService.Scope instead. This enum is going to be removed in version 1.7.0-beta.'
I did not modify the code other than adding in the client_ID and client_secret. Other than that, it appears to run...
I'll also mention that I am using the nuget Google.Apis.Auth package.
The code behind the DriveService.Scopes warning is using DriveService.Scopes not Google.Apis.DriveService.Scopes (look at the code on the link; mine is the same).
With the google admin api being deprecated and google breaking the old api almost every other week it seems, I'm anxious to get on the new API. However, with what I'm seeing here I'm wondering if that's a good idea or not. I could be trading the frying pan for the fire. With that said, what are we supposed to be using if your current example is already obsolete?
First of all you should use the latest version of the library, that's the version that we maintain, provide fixes, new features and so on. You can get it using NuGet.
The sample code in the page you mentioned wasn't updated lately. Take a look in our samples repository (and specifically in the Drive API sample).
Google.Apis.Auth is the right package to use. The reason the old package (Google.Apis.Authentication) is obsolete is based on the fact the we wanted to support different Windows platforms like WP, Windows 8 applications, ASP.NET MVC. We also simplified the OAuth2 "dance" which was so complicated before.
Last thing - If we make any incompatible changes in the library we document them in our announcement blog, so our users will be able to make the right adjustments . I recommend you subscribing to this blog to get updates about our library.
Hope everything is clear now :)