First, after I updated the Cloud SQL Admin API via Eclipse, I noticed that some of my classes broke. Apparently the API had changed.
Specifically, methods in ExportContext had changed; setDatabase() was no longer present and had been replaced by setDatabases() and setTable() had been replaced by setSqlExportOptions().
BUT, the problem is, after updating my code to the new API, it won't run.
New Code:
ExportContext exportContext = new ExportContext()
.setFileType("SQL")
.setDatabases( Arrays.asList(srcDatabase) )
.setSqlExportOptions( new SqlExportOptions().setTables( new ArrayList<String>(tableNames) ) )
.setUri(dumpUri);
Here is the exception:
(com.google.api.services.sqladmin.model.ExportContext.setFileType(Ljava/lang/String;)Lcom/google/api/services/sqladmin/model/ExportContext;)
java.lang.NoSuchMethodError: com.google.api.services.sqladmin.model.ExportContext.setFileType(Ljava/lang/String;)Lcom/google/api/services/sqladmin/model/ExportContext;
How can i fix this?
The new version of the Cloud SQL Admin API, v1beta4, was recently released and it includes a few changes like the ones you are saying. For example setSqlExportOptions needs to be set for exporting data in SQL format.
The old version, v1beta3 is still available. My guess is that you never specified an API version and eclipse automatically generated the client code for the latest version. Make sure you specify which version you want to use.
Related
Recently I added a couple of new callable firebase cloud functions to my mobile app. The thins is, once I deployed and tested my functions I was not able to invoke them failing with an UNAUTHENTICATED error. I re-deployed all my functions and still, the old ones can be invoked while the new one failed with UNAUTHENTICATED. I did some research and people were talking about the version of the Node. I upgraded the Node version but it did not work out. I upgraded the firebase-functions version and the firebase-admin version. No luck.
I tried to browse to the URL of one of the older callable cloud functions that I have deployed before and it was ok. Then I tried to browse to a newly deployed https callable firebase cloud function. I saw this message in my browser:
Your client does not have permission to get URL /function_name from this server.
Any ideas what is going on here?
Thanks
Ok, here is what I found.
According to this page: https://cloud.google.com/functions/docs/securing/managing-access-iam#allowing_unauthenticated_function_invocation
As of January 15, 2020, HTTP functions require authentication by
default. You can specify whether a function allows unauthenticated
invocation at or after deployment.
Here is what you do:
1- Browse to the link above
2- Find "Viewing users" section and click on the "Go to Google Cloud Console" button.
3- On the screen that opens, you will see a list of your deployed cloud functions.
Select the one that is throwing the UNAUTHENTICATED error.
Click the Add Member button that appears on the right pane.
4- Select Cloud Functions Invoker role
5- Type allusers inside the "New Members" box. Select allUsers or allAuthenticatedUsers (Try with both to see which one works for you)
6- Hit "Save"
You should be able to invoke your firebase https callable cloud function now, and the UNAUTHENTICATED error should be gone.
I was having the same problem and what worked for me, was as simple as changing the function's name in the file (and of course where it was called) and redeploying it, which automatically deleted the first one.
EDIT #1: I've just had the same problem again and this time, I didn't rename the function. I only deleted the function manually inside firebase and then I redeployed it. It also works.
EDIT #2: Once again I had the same problem. However, this time I couldn't fix it with the alternatives above. I had upgraded my firebase-tools and something on this new version (10.3.1) was conflicting. Until I figure out what is the problem, I just downgraded firebase-tools (following this: https://stackoverflow.com/a/57262942/14608654) to version 10.2.2 and the error vanished.
in my case, I write wrong function name in my Flutter app
final callable = _functions.httpsCallable('wrong function name in here');
I am trying to use the Keycloak docker image with a non-standard database (HANA-DB).
Modifying the configuration as described in the documentation worked fine and keycloak connects to the database. The remaining problem seems to be that the Liquibase migrations can not run because Liquibase does not know how to handle HANA-DB out of the box.
Of course, there is an extension library (https://mvnrepository.com/artifact/org.liquibase.ext/liquibase-hanadb/4.0.0) that adds this capability to Liquibase. Now my question: How do I get Keycloak's Liquibase to use this library?
I already tried:
Packaging the library into its own module and adding a dependency to it in Keycloak's Liquibase module
Adding the library as a second resource-root to Keycloak's Liquibase module
Both did not work, i.e. Liquibase is still not recognizing the "HDB" database.
What would be the correct way to do this?
I actually made it!
The way i achieved it is not perfekt, but keycloak 11.0.2 Docker Image is running.
Keycloak with Hana and Liquibase Migration to Hana DB is working and by now all tests for us have passed.
I'll just give you a short description what I did. And maybe write a little Blog Entry for that.
Basically you answer helped me at some point and you were on the right track.
What I did:
Creating another DB Vendor for JBoss CLI Bootstrap Scripting (https://medium.com/#victor.boaventura/keycloak-using-alternative-databases-e2b13576c457).
Hana DB Driver also needed a Global Module /subsystem=ee:write-attribute(name="global-modules",value=[{"name" => "jdk.net","slot" => "main"}, {"name" => "org.liquibase","slot" => "main"}]) (JBOSS CLI)
Keycloak did not autodiscover the correct Hibernate Dialect, so had to add that as well: /subsystem=keycloak-server/spi=connectionsJpa/provider=default/:write-attribute(name=properties,value={"dataSource" => "java:jboss/datasources/KeycloakDS","initializeEmpty" => "true","driverDialect" => "org.hibernate.dialect.HANAColumnStoreDialect","migrationStrategy" => "update","migrationExport" => expression "${jboss.home.dir}/keycloak-database-update.sql"})
Updated the Liquibase Module to Version 3.6.3 and added Liquibase Hana DB Adapter 3.9.0 (https://github.com/liquibase/liquibase-hanadb) as second resource root in same module. (Was kinda tricky to get the versions working) Also the Module needed another dependency on 'org.slf4j' to get the Logging to work.
At this Point I struggled with Liquibase Package Scanning and Keycloaks exclusion on 'liquibase.ext'. Thats why I had to add the SystemProp 'liquibase.scan.packages' (Thanks to you here :))
liquibase.scan.packages=org.keycloak.connections.jpa.updater.liquibase.lock,liquibase.change,liquibase.changelog,liquibase.database,liquibase.parser.core.xml,liquibase.precondition,liquibase.datatype,liquibase.serializer.core.xml,liquibase.sqlgenerator,liquibase.executor,liquibase.snapshot,liquibase.logging,liquibase.diff,liquibase.structure,liquibase.structurecompare,liquibase.lockservice,liquibase.sdk.database,liquibase.ext
After that Keycloak recognized Hana DB for Liquibase and the Migration started. I was super happy, but one Problem solved the next comes up...
2 of the liquibase changelogs were not working with Hana DB due to some SQL specifics. Thats why I created two patches and applied them to the keycloak-model-jpa module. Basically they already handled special cases (that failed) for oracle, so I just added 'hana' to every preCondition, where 'oracle' was mentioned and it worked!
This is basically my solution. If you have any questions please feel free to ask them here or contact me.
It turns out, that adding the library as a second resource-root in Keycloaks's liquibase module is actually working. It does not get loaded because Keycloak removes liquibase.ext from the service loader used to find liquibase extensions.
This can be worked around by using the liquibase.scan.packages system property, though.
For all those trying to make Keycloak working with HANA:
Overriding the liquibase.scan.packages system property causes the library to be loaded
Now, a class (LoggingService) from liquibase that is referenced in the liquibase-hanadb library, can not be found because it was introduced in liquibase 3.6 and Keycloak comes with 3.5.5.
When hacking a more recent version of liquibase (3.6.0) into Keycloak's modules, for some reason a changeset only intended for DB2 is being run, causing errors. I suspect an incompatibility between Keycloak's changelogs and the updated liquibase version.
I gave up at this point.
I'm currently in the middle of upgrading our API from v0.12 of Sails to v1. Not the easiest task, but will be worth it.
The current problem I'm having, is converting our old "ModelName.query" calls to the new style, which is supposedly "sails.getDatastore". Great, fine.
Except, that when trying to do this in config/bootstrap.js, I constantly get the error "sails.getDatastore is not a function".
Yes, I am using the default sails-hook-orm, the .sailsrc has it turned on explicitly; and yes, I have globals turned on.
Is the problem that the function isn't registered until after bootstrap? Because that is not an option for us; bootstrap is validating our database schema before lift (custom code, using native queries), so our production servers fail to deploy if we missed a database update. It eliminates a ton of human error.
Thanks for taking the 1.0 plunge!
I'm not sure what you mean by the "default" sails-hook-orm -- that hook is installed directly as a dependency on each Sails 1.0 project -- but I can almost guarantee that the version you're using is not correct. I would do:
npm cache clean
npm install sails-hook-orm#beta
in your project to make sure you get the latest (currently v2.0.0-21). It adds getDatastore to the app object when it initializes.
before update am using tweetinvi 0.9.07 and it works fine when I update it with the latest version it will generate several errors which are in snapshots
Tweetinvi credentials has changed in version 0.9.9.x.
You can find the documentation regarding this here.
TwitterCredentials.SetCredentials has changed to Auth.SetUserCredentials.
TwitterCredentials.ExecuteOperationWithCredentials has changed to Auth.ExecuteOperationWithCredentials.
Also please note that Auth.ExecuteOperationWithCredentials uses the credentials defined by creds. You therefore do not need to call Auth.SetUserCredentials inside a lambda of ExecuteOperationWithCredentials.
Finally please note that you can now create credentials via the new TwitterCredentials(...).
Using a powershell script to deploy a CRM Package works well, but I am running into some unexpected behavior.
The package has 1 unmanaged solution that it uploads. It works perfectly if the solution does not exist on the target CRM organization. However, if the solution does already exist on the organization and I try to deploy it again with some changes, it will not work. The changes are not uploaded and I do not get any errors.
If I change the version number in the solution (from 0.0.1 to 0.0.2, for example) then uploading it works as expected.
I would rather not change the version every time though, and since manually uploading an unmanaged solution with the same version number works perfectly I would expect the script to be able to do it as well.
I tried using the CRM Package Deployer method of importing a package to see if it would work as I expect or if it would show any error messages.
It's messages show:
Skipping solution MySolution. Version 0.0.2 of the solution is already loaded.
So it appears that if a solution with the same name and version number exists in the organization then it will be skipped entirely. This is sort of unfortunate.
It seems I'll have to implement a workaround. I see two options:
The DeployPackage script deletes the solution in the target CRM organization (if it exists) before attempting to upload.
My ExportSolution script changes the version number every time it runs.