[MonetDB-users] monetdb_sql/mal() ?
Hello. I've been looking at Debian packages, and the followig things struck me: -1- You have two shared libraries: libembeddedsql.so and libembeddedmal.so which are distributed, but there's only headers for the *sql.so one. You have to write your own for the *mal.so one. -2- In the source, there are two libembeddedclient.c.in files: one for sql, one for mal. The one for sql contains a monetdb_sql() function call. The one for mal does not. Is there a good reason for this? Or is it simply the way it currently is? All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/
I looked at the sources for these a while ago. As I recall it struck me the sql version had some extra stuff for no particularly good reason. At any rate, there are only 2 really minor differences that distinguish the two (a reflection on how well-thought out the layering in Monet is): 1. snprintf(buf, sizeof(buf), "include sql;\n" // <------ this is added from the MAL version to ensure the sql module is init'd "in := \"" PTRFMT "\":streams;\n" "out := \"" PTRFMT "\":streams;\n" "mapi.malclient(in, out);\n", PTRFMTCAST in, PTRFMTCAST out); 2. streams = mapi_embedded_init(&mid, "sql"); // <------ paramter changed from the MAL version (from mal to sql) Really they're quite trivial, you could easily do the same stuff in your code. The only challenging thing about that approach is going to be the make process. On Sun, Jan 10, 2010 at 8:17 PM, Guillaume Yziquel < guillaume.yziquel@citycable.ch> wrote:
Hello.
I've been looking at Debian packages, and the followig things struck me:
-1- You have two shared libraries: libembeddedsql.so and libembeddedmal.so which are distributed, but there's only headers for the *sql.so one. You have to write your own for the *mal.so one.
-2- In the source, there are two libembeddedclient.c.in files: one for sql, one for mal. The one for sql contains a monetdb_sql() function call. The one for mal does not. Is there a good reason for this? Or is it simply the way it currently is?
All the best,
-- Guillaume Yziquel http://yziquel.homelinux.org/
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Jason Kinzer a écrit :
I looked at the sources for these a while ago. As I recall it struck me the sql version had some extra stuff for no particularly good reason. At any rate, there are only 2 really minor differences that distinguish the two (a reflection on how well-thought out the layering in Monet is):
I'm not really qualified to comment on the layering. But the header issue in the Debian package is annoying.
Really they're quite trivial, you could easily do the same stuff in your code. The only challenging thing about that approach is going to be the make process.
Yes. It is not that difficult: the embedded_mal symbol is available, so you just need some stub code around everything... I was essentially wondering whether or not there was anything peculiar that i would have overlooked. Seems not. Thanks a lot. By the way, as I'm doing OCaml binding work, I was looking at how OCaml could be used to design queries in a statically type safe way. I stumbled on this: http://eigenclass.org/hiki/addressing-orm-problem-typed-relational-algebra How hard would it be to implement a query compiler from such a typed relational algebra? -- Guillaume Yziquel http://yziquel.homelinux.org/
By the way, as I'm doing OCaml binding work, I was looking at how OCaml could be used to design queries in a statically type safe way. I stumbled on this:
http://eigenclass.org/hiki/addressing-orm-problem-typed-relational-algebra
How hard would it be to implement a query compiler from such a typed relational algebra?
Hmmmm, well, it doesn't sound particularly easy. You basically take whatever effort would be involved with compiling down from a string-based form (say, what Hibernate QL does) and then add on top of that magic to get your relational algebra representation to play nicely with the Ocaml type system. (Basically you're creating an embedded DSL). Are you considering targetting SQL or MAL? In a sense MAL seems ideal since the BAT operators implement a relational algebra already, so it would be a fairly direct mapping. Well, except then you're inventing the concept of tables from scratch. In any case, I suspect the main difficulty here will be in the frontend... BTW, Scala has a SQL DSL as well you might want to check out for further inspiration (it's taking heavy advantage of implicits, which are sort of like type classes - Ocaml doesn't have these of course, but maybe still interesting).
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Jason Kinzer a écrit :
By the way, as I'm doing OCaml binding work, I was looking at how OCaml could be used to design queries in a statically type safe way. I stumbled on this:
http://eigenclass.org/hiki/addressing-orm-problem-typed-relational-algebra
How hard would it be to implement a query compiler from such a typed relational algebra?
Hmmmm, well, it doesn't sound particularly easy. You basically take whatever effort would be involved with compiling down from a string-based form (say, what Hibernate QL does) and then add on top of that magic to get your relational algebra representation to play nicely with the Ocaml type system.
I think this is the part that has already been done by Mauricio in the link above. http://eigenclass.org/repos/gitweb?p=relational.git;a=summary http://eigenclass.org/hiki/typed-relational-algebra-in-OCaml
(Basically you're creating an embedded DSL). Are you considering targetting SQL or MAL?
I'm targetting MAL.
In a sense MAL seems ideal since the BAT operators implement a relational algebra already, so it would be a fairly direct mapping.
This still needs to be checked out thoroughly, but yes, that's the idea.
Well, except then you're inventing the concept of tables from scratch. In any case, I suspect the main difficulty here will be in the frontend... BTW, Scala has a SQL DSL as well you might want to check out for further inspiration (it's taking heavy advantage of implicits, which are sort of like type classes - Ocaml doesn't have these of course, but maybe still interesting).
I do not doubt it's interesting. But SQL is not my main goal here. If Mauricio's relational algebra is lean enough, the balance between static type checking and SQL's quirks will be in favour of Mauricio's work. Besides, It would seem to overlap with Mauricio's work which already provides some parsing from his OCaml algebra to SQL. But the thing is, you've got the SQL string created at OCaml compile time. What would be nice is to have the SQL -> MAL compilation also happen at the same time you compile the OCaml program. (Moreover, it seems to me that MAL comes in two flavour: a human-readable one and a machine readable one. Is that correct? If yes, I'm aiming at the machine readable one.) How easy would that be? Do you need a running embedded server for that, or simply a subset of the functionalities of the MonetDB shared libraries? -- Guillaume Yziquel http://yziquel.homelinux.org/
participants (2)
-
Guillaume Yziquel -
Jason Kinzer