I am not interested in a complete ORM; what I am interested is when the object-oriented language supports a SQL-R-like object. In R, the object is called a data.frame and the package "Pandas" supplies a similar data frame object to Python. https://pypi.python.org/pypi/pandas/0.10.0/
R as I have mentioned has fantastic interfaces to SQL databases that allow one to pass a query and have the result populate a data frame. The data frame in R or Python can be fed to a machine learning algorithm (scikit learn on Python) or to a plotting package such as ggplot or bokeh. https://pypi.python.org/pypi/ggplot/0.6.8 http://bokeh.pydata.org/en/latest/ http://scikit-learn.org/stable/ What I want to do is to demonstrate short scripts in R and Python to accomplish the same task. I don't want the Python scripts to be longer and more complicated because Python has an lower level interface to SQLite. When I tried to do this two years ago, the SQLAlchemy package (for example) did not understand SQLite VIEWS and one had to write an explicit loop to build the data frame (which would make the Python code longer and more complicated than the R code). I can't ask for enhancements to the SQL CLI because that is a standard that was written for communication with non-object oriented languages such as C and COBOL which do not have standardized SQL-table-like objects (one could of course write a library for C to implement a data frame -- R itself is written in C and so are most implementations of Python), but S (the proprietary ancestor of R) was written so Bell Labs scientists did not have to learn C or FORTRAN. Rather than invent a whole new spec out of whole cloth, I thought the JDBC spec might be a good start at a high level interface and would have the added benefit of being cross platform. There seem to be a lot of SQL GUIs written in Java that use JDBC; so JDBC must be doing something right? There also appears to be a Python interface to ODBC. Microsoft should have a strong interest in having a good ODBC driver for SQLite (having adopted SQLite in MS Windows) because Microsoft products such as C#, MS Access and MS Excel all could consume SQLite data via ODBC. Perhaps Microsoft could issue a consulting contract (to Dr. Richard Hipp) for an high quality ODBC driver for SQLite? But, is ODBC cross-platform? I agree that error messages are an issue -- is this a problem with the JDBC/ODBC specs, the implementations or is the entire technical approach beyond redemption? Jim Callahan Orlando, FL <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, Jan 30, 2016 at 6:03 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 30 Jan 2016, at 8:13pm, Yannick Duch?ne <yannick_duchene at yahoo.fr> > wrote: > > > In my opinion (which some others share), OO is a bag of miscellaneous > things which are better tools and better understood when accosted > individually. Just trying to define what OO is, shows it: is this about > late binding? (if it is, then there sub?program references, first?class > functions, or even static polymorphism and signature overloading) About > encapsulation? (if it is, then there is already modularity and scopes) > About grouping logically related entities? (if it is, there is already > modularity, and sometime physically grouping is a bad physical design). > > There are a number of problems in using a relational database for > object-oriented purposes. One is that to provide access to stored objects > you need to access the database in very inefficient ways which are slow and > are not helped by caching. You can read about some of the problems here: > > <https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch> > > There are databases designed from the ground up as OO databases. Or > rather as ways to provide persistent storage for objects. They tend to be > non-relational databases, optimised for efficiency in making changes to > objects rather than searching and sorting. > > You can use SQLite like this. In fact implementing persistent object > storage in SQLite would be a wonderful exercise for a programming class. > But it might result in a solution too slow to be useful for real programs. > The biggest pointer for this is that it hasn't been done. There's no > library to implement persistent object storage that everyone knows about. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
