LVOOP Relational Mapping

[d_laub]

Hi all! I met a number of you at NI Week, and I'm looking forward to getting more involved with LAVA.

I've been working on an Object-Relational-Mapping (ORM) system for LabVIEW objects. I want to gauge the interest in developing this into an open-source package.

The jist of it is a 'presistable object' class that can be inherited. The child class overrides a VI to provide the necessary SQL schema information and the object's internal data (can be as simple as passing the child's private data as a cluster variant, plus a few constants) and a VI for the parent to set data with. The parent class then provides the Load, Insert, Update, and Delete functionality by dynamically building and executing the queries, and acting on the child.

I've gotten this far, but there's a huge list of features I haven't gotten to implement yet, though I think many will be easy once a versatile enough architecture is built. Things like:

- Connection pooling

- Atomic transactions with roll-back

- Aggregation:

. - Proper handling of object relationships and heirarchy

. - Allow for collections of objects, and optimize the SQL queries to batch operations together

. - Allow selective child loading (i.e. a 'car' class contains a collection of 4 'tyre' classes, they may (or may not) be loaded at the same time as 'car')

(and many more)

Current status: still contains some proprietary code, I'd have to remove this first before I could share it, and it's not well documented yet. It's on its 3rd iteration and at the point where I've learned enough that I'd want to start again fresh to improve the architecture, but I think I want to attempt to implement aggregation first, since I'm sure many new architectural issues will surface. I could really use input on the architecture of the design, especially from people familiar with LVOOP or ORM's. There's also a lot of good old-fashioned work to fill out all the features and test everything.

If you're familiar with some of the ORM's out there, this is nontrivial, but useful and challenging. There will also be some good spin-offs. I've already built a great library that simplifies and extends the LV db toolkit (like load/save cluster with strict late-bound typing, NULL representation for native LV types, etc.).

Let me know if you're interested in this kind of project (to use or contribute to).

Cheers!

- Dan Lauber

[Phillip Brooks]

Welcome to LAVA!

Awsome timing on the post. I'm working on a smallish database project and just started reading about Object-Relational Mapping last week. I'm trying to use this project to (finally!) force myself to use LabVIEW OOP.

My database is mostly transaction based with several distinct object tables, each with a corresponding history table. The history tables are identical in structure. The existing database is messy, so I am refactoring it. Since I wanted to keep OOP in mind, I started researching and read about ORM. I was bummed out and confused, and then BAM, you joined!

I can't contribute much at this point, but based on my research last week and reading your post, I would suggest that you look at the following LAVA threads:

• LapDog - an open source mid-level api for LVOOP
• Examples: Messaging with objects, Command and State Patterns, configuration with XML

I'll be looking for more posts, and will probably ask a few questions (if I don't get lost and abandon the OOP portion of my project).

[Yair]

I agree that this interesting and could probably integrate well in LD. I asked Daklu to add you to the discussion there.

[Daklu]

Dan,

I have absolutely no experience with ORM and the last time I did anything substantial with databases was in the late '90's using VB6. So while I personally wouldn't be much help to you, it looks like there are other developers who would.

LapDog has a private community on NI's website. (We'll open it up eventually but since we're just starting out I'd like to keep it small.) If you'd like to see what we're about post your NI logon name and someone will send you an invite. There's not a lot of activity just yet, but I've posted some documents outlining my vision and those should give you a sense of our direction.

-Dave

"I asked Daklu to add you to the discussion there."

Jon started that private discussion thread--I can't add members. Regardless I'd like to move all discussions over to the community site so we have a single point for information.

[jgcode]

Yer, that discussion thread is dead now anyways (it was only for NI Week).

[Phillip Brooks]

Yer, that discussion thread is dead now anyways (it was only for NI Week).

Gaaah!

Where has the discussion gone? I feel like Alice down the rabbit's hole; or maybe "there is no spoon..."

[Daklu]

Gaaah!

Where has the discussion gone? I feel like Alice down the rabbit's hole; or maybe "there is no spoon..."

Erm...

"Regardless I'd like to move all discussions over to the community site so we have a single point for information."

There is a spoon, we're just hiding it while we figure out what the spoon will look like.

[Aristos Queue]

Erm...

"Regardless I'd like to move all discussions over to the community site so we have a single point for information."

There is a spoon, we're just hiding it while we figure out what the spoon will look like.

I hate to tell you this, but if you're creating a new copy of the conversation that will branch off the old one, that's called a "fork", not a "spoon".

:-)

[Phillip Brooks]

I hate to tell you this, but if you're creating a new copy of the conversation that will branch off the old one, that's called a "fork", not a "spoon".

:-)

[Wire Warrior]

So....what your saying is "There is no spoon?"

Jason

[Daklu]

I hate to tell you this, but if you're creating a new copy of the conversation that will branch off the old one, that's called a "fork", not a "spoon".

Could be, but forking and spooning are often closely related, so I didn't make the distinction.

[Yair]

There is no spork.

[d_laub]

Hmm... So I spoke with my employer and he seemed a little less thrilled about contributing to an open source project than I anticipated. I think that having other contributors would accelerate the development, and our company has no interest in marketing this kind of thing, so I'll keep at it.

-Dan