I was with Julia 0.5 and used PostgreSql.jl to connect to the Database. It internally uses DBI.jl dependency.
Now upgrading to version 0.6, this has stopped working. The only alternative I could find online is LibPQ.jl. However, the library is a huge inconvenience to use.
Does anyone here have experience with connecting to Postgres from Julia? How did you achieve it?
Please shoot any questions if I have missed giving any information.
I achieved it by writing and using PostgreSQL.jl, and later LibPQ.jl. PostgreSQL.jl was very much a novice effort, and I stand by LibPQ.jl as the better option. Briefly in development we used ODBC.jl, but found that difficult to configure, inflexible in output, and slow. Using LibPQ.jl has simplified our database interaction code and improved transfer speeds.
I found it more useful to write a package that supported an existing general data interface (DataStreams.jl) than to write and maintain a database interface that I wasn't personally invested in. There's certainly opportunity to do so, and to support the interface using LibPQ.jl, but it is no longer a personal goal of mine.
I am also happy to discuss any inconvenience you have using LibPQ.jl in an appropriate forum (tagging me on the JuliaLang Discourse site always gets a response).
Related
Say we have a SystemC model of decade counter and I want to verify SystemVerilog Counter RTL using SystemC model. How can we connect these two in SV/UVM based testbench so as to communicate between them.
Mentor developed a free package called UVMConnect that was developed specifically for the application you are asking about. See https://verificationacademy.com/topics/verification-methodology/uvm-connect. You will need a simulator that supports SystemVerilog and SystemC simulating together, like Questa.
If you're using QuestaSim I think UVM-connect from Mentor is the way to go. When I first used it(4 years ago) it was very buggy and gave the most cryptic segfault errors I've ever seen. But, with help from the Mentor support I managed to overcome them and get stuff done. It should be more stable now, but if you have problems with it don't hesitate to contact Mentor support. They are very responsive.
However, if you're using Cadence tools and/or the e language I think that UVM-ML from Cadence is a much more comprehensive solution. It allows you to connect components written in any combination of languages(SV-SC, SV-e, SC-e) and it has nicer documentation and examples. I understand it's also compatible with all simulators now. You can find it here : http://forums.accellera.org/files/file/65-uvm-ml-open-architecture/
Not sure what Synopsis folks recommend for their tool suite. Maybe someone who used them can offer more information on this. But I'm guessing that both UVM-ML and UVM-Connect could work since their makers claim that they are portable.
And lastly, if you're planning to use SystemC as a verification language(very unlikely but just for the sake of diversity) there is something called UVM-SystemC which is basically a clone of SV-UVM written in C++/SystemC. It's currently in its alpha release and it lacks many features(register modeling, constrained randomization, coverage collection, etc.). It feels a lot like SV-UVM and I think it's a nice toy to play with in your spare time if you can't afford a commercial simulator license. You can find it here http://accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-alpha1.tar.gz
We are planning to migrate from Prevayler (http://prevayler.org/) to db4o (http://www.db4o.com/), so we wanted to know experiences, pros and cons, and best practices to move forward. What do you think about it? Is it a good solution? Or, maybe moving forward with a NoSQL standard solution would be better? (Such as MongoDB or CouchDB). Thanks!
we use db4o as main db in our production environment (both embedded and client/server), so i am going to share some of my experiences.
Pro:
- very easy for development (you just implememt data classes)
- support both embedded/client server under the same interface, which makes it easy to unittest
- decent performance for small projects
Cons:
- db4o is no longer developed so it's quite dead project, and you wont get much of support for it
- [client/server] everytime you change model you need to redeploy server (not talking about the fact that you need to host server app yourself)
- [client/server] performance degrade with more clients connected - not possible to scale
Summary: db4o is very good as embedded db (mobile app, desktop local db), but if it comes to server application you get into troubles
Given that I did not receive so much feedback, we gave it a try. So far, it seemed to be a good option for a embedded database, that makes much easier the deployment. So, we wrote again the whole persistence layer, with their unit tests and seemed to work fine.
Then, we tried with real data, and we start to have some weird Null Pointers, and we did not know why. Then, we started to read and we found this issue: http://www.gamlor.info/wordpress/2009/09/db4o-activation-update-depth/.
We've been trying to solve for a few hours, but then we decided no to spend more time on it, and found another way. CouchDB, OrientDB or MongoDB are still on our list.
We are doing research right now on whether to switch our postgresql db to an embedded Derby db. Both would be using glassfish 3 for our data layer. Anybody have any opinions or knowledge that could help us decide?
Thanks!
edit: we are writing some performance tests ourselves right now. Looking for answers more based on experience / first hand knowledge
I know I'm late to post an answer here, but I want to make sure nobody makes the mistake of using Derby over any production-quality database in the future. I apologize in advance for how negative this answer is - I'm trying to capture an entire engineering team's ill feelings in a brief Q&A answer.
Our experience using Derby in many small-ish customer deployments has led us to seriously doubt how useful it is for anything but test environments. Some problems we've had:
Deadlocks caused by lock escalations - this is the biggest one and happens to one customer about once every week or two
Interrupted I/Os cause Derby to fail outright on Solaris (may not be an issue on other platforms) - we had to build a shim to protect it from these failures
Can't handle complicated queries which MySQL/PostgreSQL would handle with ease
Buggy transaction log implementation caused a table corruption which required us to export the database and then re-import it (couldn't just drop the corrupted table), and we still lost the table in the process - thank goodness we had a backup
No LIMIT syntax
Low performance for complicated queries
Low performance for large datasets
Due to the fact that it's embedded, Derby is more of a competitor to SQLite than it is to PostgreSQL, which is an extremely mature production-quality database which is used to store multi-petabyte datasets by some of the largest websites in the world. If you want to be ready for growth and don't want to get caught debugging someone else's database code, I would recommend not using Derby. I don't have any experience with SQLite, but I can't imagine it being much less reliable than Derby has been for us and still being as popular as it is.
In fact, we're in the process of porting to PostgreSQL now.
Derby still is relatively slow in performance, but ... where ever your Java application goes your database server goes, completely platform independent. You don't even need to think about installing a DB server where your Java app is being copied to.
I was using MySQL with Java, but having an embedded implementation of your Database server sitting right within my Java App is just stunning and unprecedented productivity, freedom and flexibility.
Always having a DB server included whenever and wherever on any platform for me is just heaven !!!
Have not compared Postgresql to Derby directly. However, having used both in different circumstances, I have found Derby to be highly reliable. However you will need to pay attention to Derby configuration to ensure it suits your application needs.
When looking at the H2 databases stats site, it's worth reading follow up discussion which comes out in favour of Derby compared to the H2 conclusions. http://groups.google.com/group/h2-database/browse_thread/thread/55a7558563248148?pli=1
Some stats from the H2 database site here:
http://www.h2database.com/html/performance.html
There are a number of performance test suites that are included as part of the Derby source code distribution itself; they are used by Derby developers to conduct their own performance testing of Derby. So if you need examples of performance tests, or want additional ones, you could consider using those. Look in the subdirectory named java/testing/org/apache/derbyTesting/perf in the Derby source distribution.
I'm not sure what you mean that Derby is embedded. Certainly that is an option, but you can also install it as a separate server.
A job came in to me that's built with CodeCharge - had a look at it and seems to be a pretty basic point-and-click site builder tool. Has anyone got any in-depth experience with it? My first reaction is one of horror and to just rebuild the code in Rails or PHP but I thought I'd ask the question first, maybe i'm missing something...
I'm currently evaluating it for use in quickly producing a back-office environment, and it seems a very comfortable way of getting an interface up and running quickly.
Once the code is generated it is simple, but easily modified for any special needs you have.
In short it is a very good tool (though it would seem that Iron Speed Designer is much better though much more expensive) for what it does - fast prototyping and almost no coding approach to developing a web application. In my opinion, not much different than a Ruby On Rails application in terms of functionality, and, I can generate the code in any language I want.
You have to realize, it is all about speed - some quality is thrown in, but it is a very generic of quality - this is NOT a custom application, mind you, the resulting code you get here might not be pretty but it is a few level higher than your average script kiddie code.
I'm seriously considering this tool for creating back-office applications for sites I develop - a fast and easy solution instead of mucking around in tables of data and useless and repetitive SQL code.
Codecharge is a powerful tool that I have used for over 10 years to build very large content management systems, CRMs and many other management type tools.
Its far from simple once you get into it, and honestly when you use a tool like Codecharge to cleanly generate your user interfaces, you end up with a healthier application that can last many many years.
For instance, I have three clients that have been running Codecharge created portals for over 10 years and they always comment how bug free they have been.
There is a learning curve to learning CodeCharge but it will also teach you what entire applications should have in place and it will please the executives every time because they can get functionality within hours or days rather than weeks or never.
Development teams will often not like it though, because they would rather hand code everything or use the latest and greatest approach to development.
Is there anyone who has used or looked into using Jitterbit as well as BizTalk? If so, what are some pros and cons of each, and which one did you go with as your final solution?
Specifically, I'm looking for SAP integration, but any input would be appreciated.
Like Rob I have not heard about JitterBit until reading your question (thanks!), I have, however, been working with BizTalk, almost exclusively, for the past 9 years; for that reason I wasn't sure I should be responding, but as Rob did, and nobody else has, I figured it's worth a couple of cents....
From the little reading I've done it seems to me that JitterBit, apart from being an open source, which has it's pros and cons, is trying to lower the entry barrier by offering a relative simple solution with the promise of rapid development and drag-n-drop approach "with no custom code".
I'll take their promise at face value, as I know nothing about it, although I have my doubts, so let's assume developing with JitterBit is really easy, there's one thing I can clearly state - developing with BizTalk isn't.
But, and that's a bit but in my view, developing with BizTalk is somewhat difficult not because Microsoft did a bad job at it, on the contrary - developing with BizTalk is somewhat difficult because Microsoft wanted to create a tool that could realistically allow enterprises to solve their BPM and integration needs well, and, in my experience, these problems are almost never simple, so Microsoft had built a server that has many capabilities, is very strong and very flexible, at the cost of complexity.
So, while any experienced technical sales guy can give you a demo of an integration scenario that is very simple, and is developed in a few minutes using a lot of drag and drop and configuration, even in BizTalk, but is this a realistic enterprise-level solution? was it a realistic scenario that was demonstrated? from my experience the answer is almost exclusively no; the problems tend to be complex, and their require a more robust solution.
So, I guess the bottom line would be - if you're looking for a one off solution, and open source is something you guys work with - JitterBit is definitely worth looking at, seeing if it's capable of helping out and has, indeed, a short learning curve (it would be important to look at maintenance, monitoring, trouble shooting, instance management etc)
If, however, you believe, as is often the case, that your solution would grow to become a BPM/integration platform in your organisation, and you need something more robust - I would put my money on BizTalk being a better candidate.
I've done a fair bit of integration with SAP, starting with the old SAP DCOM connector. More recently I've been involved in the selection of an integration platform to serve in an Enterprise Service Bus pattern.
We did web service samples to connect to SAP on a number of platforms, including BizTalk, Mule, Netweaver, Webmethods and Tibco. Webmethods won out based on licensing and capability, though BizTalk and Netweaver both had very high marks.
Jitterbit was not part of the evaluation - in fact I had to look it up to be sure I understood your question.
If your goal is just to be able to call an RFC, the .NET SAP connector works well.
If your goal is to expose a web service to wrapper a process in SAP, then BizTalk is good, but I recommend you see if your organization already has netweaver licensed as there are many web services available directly from SAP with no coding.
My recommendation is to avoid Jitterbug and Mule for the enterprise for now - unless Open Source is actually a popular thing at your place of employment. Netweaver and BizTalk are very robust, polished products.
If you are looking for something you can ship easily, then Jitterbug may make more sense. Though generally I'd recommend you define it as a web service call, and look to your customers technology stack for the most appropriate integration technique.
More context of what you are looking to achieve will enable a more accurate answer.
Michael,
We use Jitterbit in our organization and we've been very successful with it in various projects. Our SAP projects use XI and Jitterbit has dramatically simplified the ability to integrate web service interfaces with the various protocols it supports.
In addition to an excellent price (and we now subscribe to Jitterbit for support) we realize great value out of the support service. If we have any questions during our implementations they seem to provide all the subject matter expertise included in the support cost, so we're quite self sufficient.
We still have many other integration solutions in our company including VB and Java programs; it's a mess, but we don't believe that any one platform will meet all of our different divisions' needs. We have been using open source, specifically Linux and Apache for many years now, although IBM and Microsoft are also prevalent here.
We went with Jitterbit as it supports protocols needed to integrate any modern system and with SOA / Web Services being our stated direction Jitterbit was a great fit for what we needed.
Given that Jitterbit is Open Source, I would encourage you to download it and try it out.
I will say it simply, I have been using biztalk and was one of the people that helped validate the 2006 training course. Biztalk by far one the best server applications for Business process that is available today. You do also have to factor in the price point is ridiculously low compared to what else is out there.