I am using the scalikejdbc library to access my Postgres database. The driver I am using is the default org.postgresql.Driver. I am trying to introduce query/result caching but I cannot find any evidence whether scalalike does this by default or if it even supports this. I skimmed through the TypesafeConfigReader class but could not find any configuration property indicative of such a functionality. My last resort would be to implement a simple application level cache but I want to know if this is supported somehow by default. In their official docs I could not find something definitive either.
The question was answered in the scalikejdbc issue tracker. So I'm quoting
There is no built-in query cache/result support at this moment. I would suggest using a different cache library such as https://github.com/cb372/scalacache to reduce method calls.
Related
Can someone tell me if "libmysql"dll" exists with a "client-side prepared statements"?
https://docs.memsql.com/concepts/v6.5/prepared-statements/
in the documentation I see that "server-side prepared statements" are not supported by MemSQL
What if I can't switch to another library? Software source code that fills the database cannot be changed
I'm not sure if there's an option for the mysql c/c++ client. You could try adding the mysql tag to the question since that's a question about a mysql client.
However, if there's no client-side option and you can't switch to another client driver, one thing you could try is using the experimental support by setting enable_binary_protocol=true. As mentioned in the docs:
MemSQL has an experimental, prototype implementation of server-side prepared statements, which is not supported in production. It is disabled by default, and may be enabled by setting enable_binary_protocol=true
It is known to work for some use cases and not work for others. Let us know how it goes if you test it out.
I'm running a Camel application on Liberty Profile server. I'm taking a message from a queue, unmarshalling, mapping then marshalling. This was working fine but now I'm getting an error that JAXBDataBinding method getContextualNamespaceMap is not found.
I think this is because there is an older version of the jar in the server libs but I don't know why it started using it.
IBM Jar: com.ibm.ws.org.apache.cxf-rt-databinding-jaxb.2.6.2_1.0.12
The issue is resolved if I switch to parent last class loading but its a very hacky way to fix it and is not a great option. Any other ideas? I'm thinking some feature or other dependency in my build may have pulled this jar in.
So it does look like getContextualNamespaceMap is only available in newer versions of the org.apache.cxf-rt-databinding-jaxb JAR than what is available in Liberty.
It might be that parentLast is the best option then. (You already know how to do this but it's documented (here). If it leads to some other issues then do follow-up with another question.
I suppose it's conceivable you might be able to look at whatever is packaged within your application and try removing a set of things and picking them up from the Liberty runtime, to avoid running in parentLast mode. E.g. if you are only referencing getContextualNamespaceMap because you have other code in your app but there is some alternative path you could have gone down entirely in the Liberty-provided modules, then in theory you could be OK.
I'm not familiar enough with the code paths in the modules in the CXF or Camel "stack" to guess whether that's a real-world likelihood though.
The javaee7 feature contained a jaxsw version that clashed with the server version. Removing the javaee7 feature has resolved this issue. Remains to be seen whether or not I will to add it back in.
I'm in the process of upgrading an existing application to .NET Core (DNX SDK 1.0.0-rc1-update2) that uses SQL Servers FILESTREAM feature for reading/writing large BLOBs to the database. It uses the SqlFileStream class to achieve this however it doesn't appear to be available in .NET Core. Here are my references in project.json:
"frameworks": {
"net451": {
"frameworkAssemblies": {
"System.Runtime": "4.0.10.0",
"System.Collections": "4.0.0.0"
}
},
"dotnet5.4": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Data.Common": "4.0.1-beta-23516",
"System.Data.SqlClient": "4.0.0-rc2-23623",
"System.Collections": "4.0.11-beta-23516",
"System.IO.FileSystem": "4.0.1-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516",
"System.Threading": "4.0.11-beta-23516"
}
}
}
I've tried searching SO and Google, both of which have absolutely nothing on the subject.
Can someone please confirm if its actually unavailable or if its in another package I'm unaware of?
I realize the question is old, but I just came across the issue - implementing SqlFileStream - listed on the github repo for CoreFX (.NET Core foundational libraries) and thought I'd mention it here. Here's a link to the issue, for reference: https://github.com/dotnet/corefx/issues/15652
To recap: The issue is implementing SqlFileStream. It's currently an open issue, but not on the horizon anytime soon. One of the contributors states "if there are any Windows specific dependencies, we may not bring it in Core."
I've actually been interested in this for a while and have taken some time over the last few days.
Unfortunately, FILESTREAM uses several NTFS and NT specific system calls (NtCreateFile, DeviceIoControl in particular, but a few others to support those as well) to manage access to the file. Also, unfortunately, as of this writing the latest MSSQL CTPs for Linux don't support FILESTREAM, and there's little clarity as to whether that's on the roadmap or where it might be (strangely, you can restore a database that supports FILESTREAM but FileTable doesn't seem to be supported).
There are two problems here: it's not clear that replacing the NT specific APIs would respect transactional integrity (or even work at all), and it's not clear that they could ever work from a non-Windows environment anyway. Because of these facts, I don't see SqlFileStream being supported any time in the near future for core.
There is some precedent for Windows Only type of low level, for example in System.Net.Socket.IOControl. SqlFileStream could perhaps take a similar path. Alternatively, it might be possible to build a specific SqlFileStream NuGet package, but have it only be supported/runnable on Windows. I'm not sure how valuable this would be though - if you're going to P/Invoke in a Windows only way to begin with, why not just P/Invoke to a .NET 4.6.x dll?
Cross posting this to the github issue: https://github.com/dotnet/corefx/issues/15652
Edit: As an alternative to P/Invoke, you could certainly create some other kind of service (RESTful, WCF, some other pipe or TCP or even memory mapped file) in .NET 4.x for a .NET Core library or application to access.
I'm working on an app written in Codename One together with the parse4cn1 library, the combination of which is a real pleasure to use. However, I need support for a few things in parse4cn1 that are not implemented, most importantly ACL and was wondering if Chidiebere has any hints on how to do this (e.g. how did you implement parse4cn1 yourself - from scratch or copying the open source Parse SDK for Android)? If I manage to do something of a decent quality I will try to share back. Thanks in advance
I never got around implementing ACLs (it's still on the TODO list). parse4cn1's interface closes resembles the Parse Android SDK interface and I'll like it to stay that way for convenience. In this case, the interface of interest would be the ParseACL which is documented here.
The actual implementation will need to be done via REST API calls.
Things to bear in mind:
We use the Android SDK API simply for defining methods and signatures for the corresponding class in ParseACL but do not use the SDKs for anything can be be done via REST.
By design, any calls requiring the master key will not be supported in parse4cn1 due to security considerations. If really needed, the functionality should be exposed via server-side cloud code.
Pull requests without unit tests for the added functionality or breaking existing tests will be rejected.
See also the Contributions section of the parse4cn1 github repo.
Good luck with your implementation and I hope to see a PR from you soon ;)
It was implemented from a Java port on top of the REST API's here but was later modified to use the SDK's to allow things like push (which are now no longer relevant).
In the past I just contributed pull a request to the project to get the fixes/features I needed. It was really easy to work with and compile.
I was starting to write a multi-Map JS library, but I see that Mapstraction does that exactly..
I really would like to use Maptraction but it looks a little old (The commit's on GITHUB) (Not a issue if it is still "supported"), also The tutorial page, the Maps do not show up in my browsers.
Any input is highly appreciated.
Thanks
Kim
Depends what your use case is - if you don't want to be tied in to any one map provider and only need standard features then, yes.
Version 2.1 of Mapstraction is currently being prepared (on the release-2.1 branch) which brings some improvements in behavioural consistency across the providers.
Because of the nature of the library development isn't continuous and tends to be reactive to changes in the underlying providers or issues being raised. That said the community is fairly active and you can sign up to the mailing list via the site.