Hi Team,
We had requirements like during couchabse deployment we had a bunch of perl scripts needs to be deployed in the customer site ( to bulk upload of profiles, add home etc…). Previously deployments were in Oracle so we did not have any issues so how we can achieve the same in Couchbase.
You can possibly use either the REST API or the Couchbase CLI to do things like setting up the cluster, configuring buckets etc. For bulk loading of data you could invoke cbimport I believe all three should be doable from within a Perl script.
@Debasis_Mallick are you asking specifically how to access Couchbase from Perl or are you asking for how to script the loading of data into Couchbase more generally?
As Vageesh mentioned, you can call the REST API or CLI from within Perl, but more generally I’d suggest you take a look at our couchbase shell: GitHub - couchbaselabs/couchbase-shell: Shell yeah!
Hi @perry thanks for your response. Actually, DEV team need any connector like C SDK or JAVA SDK so that they can run those scripts. They had around 40-50 perl scripts which will be difficult to convert to any other scripting language ( Python, Java) because they need to be tested thoroughly.
Thanks,
Debasis
Understood. Given that you’re migrating from Oracle, would it make sense to use SQL++? You can do that pretty easily through a REST API which you can access from within Perl: https://docs.couchbase.com/server/current/n1ql/n1ql-rest-api/index.html
Hi @perry as you told above is there any way we can connect Couchbase from Perl.
Thanks,
Debasis
Hi @Debasis_Mallick - currently there is no native Perl connector/SDK for Couchbase. Your best option is to call the REST API.
Thanks @perry. Is there any plan of Couchbase to release connector for perl in near future. Regarding REST API calls with perl script, I feel it will be difficult as there 800 to 900 lines of code . If we change those then we need to perform testing for those scripts to work as expected.
Thanks,
Debasis
Unfortunately I’d have to say that there isn’t any plan at this time for a native Perl SDK. However, we are working on some future APIs that will hopefully make it easier to access from a variety of clients.
Stepping back a second, even if we did have a native Perl SDK, it still would likely not be a drop-in replacement for whatever you’re using today, so a large amount of rework and testing would still exist right? I think it might be worth a conversation with our Professional Services teams and partners on how best to meet your requirements overall rather than a 1-for-1 swap.
Maybe going through perl’s existing ODBC/JDBS drive would work?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.