[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Questions on using orm


I've integrated using orm (and thus sqlite3) for persistent storage in the project I am working on, but I have a couple of questions. I am not sure if I have misunderstood something, or what I have noticed is by design...

So let's say I have the following:

type book = {
  book_name : string;
} and chapter = {
  chapter_fk_book : book;
  chapter_name : string;
} with orm

let db_name = "book.db"
let book_db = book_init db_name
let chapter_db = chapter_init db_name

let some_book = {
  book_name = "My book";

let some_chapter = {
  chapter_fk_book = some_book;
  chapter_name = "Introduction";

Question 1: is there any way to actually use foreign keys to query?

I would like to do basically:

SELECT c.* from Chapter c, Book b where b.book_name = "My book";

At the moment, I am forced to scrap foreign keys all together and hash my objects by feature combinations that make the hashes unique.

This also brings me to my second questions...
Question 2: is there any way to do cascading deletes?

chapter_delete ~recursive:true ~db:chapter_db some_chapter

This does something I cannot really envision ever needing...It allows me to delete the chapter _and_ the book (doesn't really seem like something too natural), where as I would like the reverse to actually happen:

book_delete ~recursive:true ~db:book_db some_book

I would expect this to delete the book and everything that actually keeps foreign keys to the book item, much like cascading deletes in SQL.

Instead, at the moment, I have to query for the book object, then use it to query for all chapters underneath, use each to call chapter_delete individually, and afterwards delete the book. There is something here that feels it won't just be optimized away for me :)

If anyone can share some insight on this, that would be great. I have a working prototype, as is, but it feels slightly contrived to potentially hack around certain things...




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.