I know that in pure object-oriented languages like Java it usually makes sense to use ORMs like Hibernate. But what would I do when writing a CRUD-type functionality in Clojure or Common LISP?
Passing around SQL as the first-order functions? But isn't having SQL in HTML-generating code very ugly?
Thanks,
Olek
Common Lisp is not a self-consciously FP language. Clojure can just use Hibernate.
For Common Lisp: databases. Here's a persistent object one. And here is the first part of a tutorial that uses it with Hunchentoot, a CL webserver and dynamic webpage toolkit. SQL in CL can look like this (which looks longer than it really is, because the SQL is horizontally formatted and the CL isn't). And if you like, this guy is working on a web framework (using CLSQL and Elephant, already linked-to) that aims at tersity, with an eye on the arc challenge.
EDIT: a recent answer expands on this.
Ur/Web may be interesting, although it's not lisp based: http://plv.csail.mit.edu/ur/
As quoted from their site:
Ur/Web supports construction of dynamic web applications backed by SQL databases. The signature of the standard library is such that well-typed Ur/Web programs "don't go wrong" in a very broad sense. Not only do they not crash during particular page generations, but they also may not:
Suffer from any kinds of code-injection attacks
Return invalid HTML
Contain dead intra-application links
Have mismatches between HTML forms and the fields expected by their handlers
Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
Attempt invalid SQL queries
Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers
an alternative set of Common Lisp tools is described in another answer
Related
I'm a software engineer in a Microsoft dominated company and now and then whilst between larger projects I am asked to create support for those larger projects. This will almost always involve some form of database interaction and being dominated by Microsoft technology our database of choice is of course Microsoft SQL Server. This makes developing support applications in non-Microsoft languages a real problem.
I've looked at Smalltalk, Go, Scheme and Factor and I always come to the same conclusion that it just isn't possible or worth the effort because ODBC support for those languages is just to fragile to be useful.
I've investigated the possibilities of creating a data access layer via a web service. This is not always the ideal situation though and with large amounts of data this can turn out to be a bottle neck.
I could clone the data and import it into a more open database system and then develop in a language of my choice. This seems like a very unnecessary step and also means that I am no longer working with primary data.
How are other C# .Net developers developing support applications that rely heavily on the Microsoft stack in non-Microsoft languages?
Instead of going the ODBC route, you might consider using native drivers in whatever language you pick. This will probably "fit" better with that language's approach. For example, Python has pymssql and cx_oracle which each conform more closely to the conventions of the language rather than trying to force it into least-common-denominator of ODBC. I'm not familiar with the languages you listed (and it's not clear if you're limiting this question only to those), but I suspect a similar situation exists there.
FreeTDS also comes up a lot in discussions of SQL Server access, but mostly from a Linux perspective.
Another variation: if you use something that uses the .Net DLR such as IronPython or IronRuby, you get to use the .Net Framework and it's ADO.NET libraries while still applying a new language approach.
I'm taking a database course and I have to write a command line application. The prof wants us to write an ESQL (embed SQL) application.
I have a feeling that this kind of technology is depreciated.
We have to use oracle precompiler to translate a esql code in c++. This kind of applications look terrible to maintain.
A php application would also work well, but they probably want a command line application to do the grading faster (unit test with input feed). What you guys think, is Embed SQL used in the industry, does it worth to ask the prof to do a java application ? Is there another technology more appropriate ?
Embedded SQL was one of the the most popular way to do SQL in C during the "old days" (C++ was not yet invented).
These days mostly we'll be using an ORM library. It is not recommended to do embedded SQL any more because, as you put it well, it depends on a proprietary pre-processor and makes code difficult to debug, manage, and maintain. It also hooks you to one single database vendor and your code will be extremely difficult to move to another database backend. Generally, we don't do it in "real life".
But as it is only a class, your prof is probably interested in teaching you SQL and database concepts. Embedded SQL is only a tool. You're supposed to learn SQL and databases, not embedded SQL in C++.
However, I believe that you're missing the point by asking about PHP and Java. Not to mention that PHP is a scripting language, and Java is another language that you can (potentially) write a processor for embedded SQL.
So your point about embedded SQL really has nothing with language choices. It has to do with the tradeoffs and balance between (1) proprietary embedded system with preprocessor, (2) using an ORM library, or a data-access library (e.g. ODBC).
Off-Topic:
I first started using embedded SQL when I was in College (that was about 30 years ago!). Actually got programming jobs out of College and still used it, but obviously it was on the way out. Never seen it used ever since 1990 or so.
Yes, but no. I have not met a single line of Embedded SQL in my 10 years in the field. I would say (and hope) this technology only exists in (some) legacy systems.
Nowadays, database related development in the industry would involve:
Direct database access using JDBC, ADO .NET, OLE DB, ODBC or native libraries (OCCI in your case).
Some sort of ORM (Hibernate, Entity Framework or a home made solution).
Some sort of data access layer based on frameworks and/or patterns (think Ruby on Rails, Active Record or a home made solution).
IMHO, home made solutions should be eradicated but they are more common than you would think. Part of this would certainly have to do with students having only experimented with outdated and inadapted tools at school...
ORM (and data access layers) related problems can be very complex and I would say very interesting to have a look at. Especially if you are a student. I would recommend delving into Martin Fowler's P of EAA.
In C++, I would have a look at SOCI.
We have to maintain on an old system here (20 years and older).
ESQL is used massively in here. The most of the problems we had while moving the software to a new OS (it was an 15 year old hpux) where with the ESQL code.
The new software we are writing are all making use of the C++ library. This gives us more readable code + our IDE doesn't say 'invalid syntax' all the time. etc..
The C++ library is in general terms very equal as how I connect to a database in .NET or Java.
Using the C++ library whe have an improvement of speed (if used wisely) and much less errors.
ESQL is deprecated by my point of view. But since we have entered an time where a lot of the written software is to update/upgrade or maintain existing systems, it is very handy to have basic knowledge of old techniques!
I haven't seen embedded SQL in an application for 10 years. The last time I saw it was in a legacy mainframe app written in COBOL. Yes, still being used at electrical utility company.
The little C++ programming I do these days doesn't involve SQL. These days most relational DB programming I encounter is one of these:
ORM (object relational mapping - hibernate or JPA)
JDBC
stored procedures (oracle or mySQL)
While this is probably outdated ( I also did ESQL ~15-20 years ago), it still may serve as a good example on how to also approach things - even if it is only for you to more enjoy ORM afterwards.
Also from my understanding LINQ in .NET is somewhat similar from the idea of embedding SQL in the host language - and LINQ seems to be quite popular.
Extracting from this to broader CS, embedded DSLs seem to be a current topic of research, so the example of ESQL as an early version my not be too far fetched from todays world.
ESQL is the prime language being heavily propagated for IBM Middleware products . Its not an Object Oriented Language but a Procedural language . Its extensively used in some places to do mapping between XMLs (alias for XSLTs) .
I am using ESql as of date on a Informix 9.x database in the legacy C++ application code that I work on as a part of my job.
While I agree to everyone that it is an old technique, and there are better options out there, I would still say it is a very neat technique. The good part is the SQL is embedded as a part of the C/C++ code flow, syntax wise and logic wise. The little syntax change that ESql carries is easy to learn, and hence I say its fun to use it.
Like Heiko mentioned, LINQ is close in the idea to ESql.
I have a project for a class which requires that if a database is used, options exist for the user to pick a database to use which could be of a different type. So while I can use e.g. MySQL for development, in the final version of the project, the user must be able to choose a database (Oracle, MySQL, SQLite, etc.) upon installation. What's the easiest way to go about this, if there is an easy way?
The language used is up to me as long as it's supported by the department's Linux machines, so it could be Java, PHP, Perl, etc. I've been researching and found info on ODBC, JDBC, and SQLJ (such as this) but I'm quite new to databases so I'm having a hard time figuring out what would be best for my needs. It's also possible there may not be a simple enough way to do this; the professor admitted he's not a database guy either and he seemed to think it would be easy without having a clear idea of what it would take.
This is for a web app, but it ought to be fairly straight forward, using for example HTML and Javascript on the client side and Java with a MySQL database on the server side. No mention has been made of frameworks so I think they're too much. I have the option of using Tomcat or Apache if necessary but the overall idea is to keep things simple, and everything used should be able to be installed/changed/configured with just user level access. So something like having to recompile PHP to use ODBC would be out, I think.
Within these limitations, what would be the best way (if any) to be able to interact with an arbitrary database?
The issue I think you will have here is that SQL is not truely standard. What I mean is that vendors (Oracle, MySQL etc) have included types and features that are not SQL standard in order to "tie you in" to their DB, such as Oracle's VARCHAR2 and so on.
When I was at university, my final year project was to create an application that allowed users to create relational databases using JDBC with a Java front-end.
The use of JDBC was very simple but the issue was finding enough SQL features/types that all the vendors have in common. So they could switch between them without any issues. A way round this is to implement modules to deal with vendor specific issues and write ways to translate between them. So for example you may develop a database for MySQL with lots of MySQL specific code in that, but then you may want to use Oracle and then there are issues, which you would need to resolve.
I would spend some time looking at what core SQL standard all the vendors implement and then code for these features. But I think the technology you use wouldn't be the issue but rather the SQL you create.
Hope this helps, apologies if its not helpful!
Well, you can go two ways (in Java):
You can develop your own classes to work with different databases and load their drivers in JDBC. This way you will create a data access layer for yourself, which takes some time.
You can use Hibernate (or other ORMs). This way Hibernate will take care of things for you and you only have to know how to use Hibernate. Learning Hibernate may take some time, but when you get used to it, it can be very useful for your future projects.
If you want to stick Java there Hibernate (which wouldn't require a framework). Hibernate is fairly easy to use. You write HQL which gets translated to the SQL needed for the database you're using.
Maybe use an object relational mapper (ORM) or database abstraction layer (DAL). They are designed to provide a standard API to multiple database backends, making it possible to switch between different backends with minimal or no changes to your code. In Python, for example, a popular ORM is SQLAlchemy, and an excellent DAL is the web2py DAL (it's part of the web2py framework but can be used as a standalone DAL outside the framework as well). There are many other options in other languages as well.
use a framework with database abstraction layer and orm . try symfony or rails
There are a lot of Object relational database frameworks, unless you prefer jdbc. For simple/small applications this should work fine.
All my (home) CF learning has so far been done using Access as a database, and as far as the DB goes I "get it". There's no database server, and no need to log on to the database or anything, and setting up table relationships is easy and visual. Oh and its essentially free to deploy.
However, I'm now working on an application that's likely to be used across several businesses and probably up to 50 concurrent users. I've heard that Access really isn't up to multi user use or production use on an app. What would you recommend as more suitable, preferably easy to grasp, with minimal tweeking needed for my SQL (I used a tool to convert to MySQL and it certainly handles concatenation differently, I dont want to have to do too much debugging), visual interface available, scalable, backupable, and whatever else I need that I don't yet know I need!
I recommend SQL Server 2008 Express. It has a great feature set, graphical UI admin tools, and you can step up easily from it to more commercial solutions as you continue to grow.
You could go with either MySQL or Microsoft SQL Server Express. Both are free and both work well.
Unfortunately you're going to have headaches converting your database no matter what you go with. Microsoft Access doesn't use standard SQL so string concatenation, functions, etc. will be different.
If you're merely using Access as a database, then naturally, Microsoft SQL Server is closest in concept (and SQL dialect) to access.
However, if your focus is on web development, the LAMP stack and specifically MySQL are a better choice. You should at least have an idea of some basic administration.
My experience is that the main challenge is going to be with data types and with string operations (sound like you have similar issues).
Generally, strive to write SQL that is portable, so it's good to read up on things that make it not portable or avoid using special tricks. If you can't do that, then abstract away using code, or even use an ORM tool.
The main benefit of Access, IMHO, is its built in support for generating UIs and reports, while hiding much of the underlying SQL. Most of the Microsoft languages (especially VB) offer similar capabilities. If you've used the UI or the forms, you'll now have to both learn a language or tool for generating UIs/forms/pages, and how to use SQL. Since you mentioned ColdFusion, I'll assume you have most of these skills already.
Before doing anything at all, I'd choose a database abstraction layer and refactor the existing code to use that.
Then it's relatively trivial to swap out your back end pretty much completely ecumenically.
If you use prepared statements, you'll also get protection against many forms of SQL injection.
I would also point out that a Jet/ACE back end was never a good choice for a web-based application because of the mismatch between the threading models and memory management of the web server and the Jet/ACE database engine (though if you use ADO, Jet is reported to be threadsafe; I don't quite understand how you can magically transform a non-threadsafe db engine into a threadsafe one with a data interface layer, but Michael Kaplan said it was so, and he is the type of person you can trust on that type of subject).
I don't have any experience with the Microsoft SQL Server Express, so I can't speak for. However, I do use MySQL with ColdFusion 8 and I'm continually impressed with the capability, flexibility, ease, community support, and speed of MySQL. PHP MyAdmin is pretty straight forward and a good web interface for MySQL. My $.02, spend it how you may.
I am currently running the local version of Caché on my system in order to determine if I can (and will) take on a new possible project.
The current project uses Delphi 7 as a front end calling a Caché dll where the business logic is stored in the database.
I have a background of Sqlserver and Firebird (and before Access and Paradox) as databases.
I use Delphi 7 for 95% of my Windows development, so I know about object programming.
I would like to recieve opinions from persons having used Caché and either SqlServer, Firebird or Oracle and having developed in Delphi (or C++ or C# - an object oriented language).
I have read the pro's and con's from other questions, but I am not asking for this, I need input from Caché developers.
Thanks in advance.
I am curious about this object database. I don't see any reference to Delphi users with this database on their web site. They do mention they have a COM interface, which might be easier than a Raw C style API (if they also have that) because at least string buffer allocation/management and your wrapper code will hopefully be simpler.
However, you will have no way of connecting to data aware controls, so I would plan on doing a lot of "roll your own" work. My intuitive opinion is that you might be the only guy on the planet using Delphi with this database. Delphi is a small fish in the development tools world though, so that might just more be a fact about Delphi more than a fact about Cache, which is a horribly NON-Googlable technology name, by the way.
You can find information about Caché by googling for Intersystems--that's really the best way. You can also search under the old name of the language, MUMPS.
I knew nothing about Caché when I started working on it fresh out of college, and I don't think it was that hard to learn. Like most scripting languages, it's best to learn by trying things out in the terminal and learning your way around.
Also, Caché has a built-in SQL mapping system so that you can have it behave like a relational database externally but still leverage some of the powerful non-relational concepts under the hood.
The company that I worked just a little time ago uses Caché and they have a bunch of projects using Caché and delphi. In fact, they uses the VISM.OCX just to connect and pass parameters to database (PLIST variable and such) but in any time they run any M command directly from application to DB, just call the routines.
Is not that hard to learn about it, but in nowdays we are leaving it! Beside Caché is incredibly fast, the lack of tools and support don't makes him a good option in nowdays...even there's a rumour that intersystems is "leaving the boat" of caché to work in a new system.
I have been working on the 2008 Caché version for a few months now. It's possible to learn\use, but extremely unpleasant. The IDE is simplistic and unhelpful with errors (it doesn't even pick up case sensitive syntax problems until it crashes at runtime). The documentation is terrible and there's nothing online, compared to to the amount of information on SQL Server or MySql. And you're learning something that probably won't be of much help in your future career. Personally, I would avoid any project that uses Caché if you have any alternative.
Friend, there are two ways to access Caché via Delphi, and is a personal project of Brazil - friends - who are developing a framework for free Caché Object Oriented.
I tell you, you're not only using Caché with Delphi, but I do not recommend. The best would be to use CSP pages, or use some better language like C # or C + +. I worked a lot with CSP and recommend to you. After all, remember, the Internet is all.
I can send you some examples - I think I have at home - just send me a message.
Sucess