On Feb 1, 2011, at 1:46 PM, Rob wrote: > Hi all - > I'm starting a project in R to write an ORM along the lines of > SQLAlchemy (but minified). I wanted to solicit opinions on a few > subjects: > 1) What is best way to start and what are the 'best' places to safely > cut corners and drop functionality? > 2) Are there any components for which I'd want to consider diverging > from SQLAlchemy's approach? > > Some obvious language-specific implementation issues exist, but I > anticipate those being resolvable with some thought. > My goal is to get something up and running in a few hundred hours > (leading me to question 3) is that sane?) that would necessarily be > very limited in scope: it would not support table creation and only > have a dialectical backing for MySQL. Many other components I could > leave as stubs. In any case, I want to avoid design decisions that > will limit future extensibility.
I haven't used R nor have I done pure functional programming since I did some APL in 1993, but I took a quick look and wikipedia seems to suggest that the "data frame" concept in R is most similar to a relational table. Seems like a good place to start. I'd also definitely take a look at LINQ which is a functional data manipulation tool and might be more relevant to R. You probably want to check out as many object relational tools as you can, the other Python ORMs, ORMs for Perl, PHP, Java (Hibernate), etc., and decide what features are important to you. The common "smaller" version of what SQLA does, in my experience, is that such tools don't have a strong separate concept of "SQL construction language" and "ORM query language". They usually have just one querying language, and it almost always is at a higher level of abstraction of SQL than SQLA's SQL language *or* its ORM, since the typical goal of such tools is to "get away from SQL". SQLA is fairly unique in its embracement of SQL and relational concepts even within its object query language. It would be a decision you'd need to make, which I would make based on writing out use cases, where you'd like to "drop the needle" on that spectrum. You also need to decide among persistence approaches - unit of work vs. active record, identity map, configurational patterns, relationship to actual table structures. Write out a whole story of usage of your tool, what it would look like, bounce it off of some other developers, etc. There's also an interesting read at http://www.agiledata.org/essays/mappingObjects.html as well as some other articles linked at the end. These are on the academic side of things, but then again so is R so maybe this will be helpful. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
