On 3-apr-11, at 22:54, Daniel Gibson wrote:
Am 03.04.2011 20:15, schrieb Fawzi Mohamed:
On 3-apr-11, at 19:28, Piotr Szturmaj wrote:
* Nice to define table structure, and what happens if the db has
another
structure.
This is a problem for ORM, but at first, we need standard query API.
I am not so sure about this, yes these (also classes for tables)
are part of the
ORM, but the normal users will more often be at the ORM level I
think, and how
exactly we want the things look like that the object level can
influence the
choice of the best low level interface.
* you want to support only access or also db creation and
modification?
First, I'm preparing base "traditional" API. Then I want to write
simple
object-relational mapping. I've already written some code that
generated
CREATE TABLE for structs at compile time. Static typing of row
fields is very
helpful here.
Very good I think that working on getting the API right there and
having it nice
to use is important.
Maybe you are right and the current DBRow is indeed the best
abstraction, but I
am not yet 100% sure, to me it looks like it isn't the best end
user abstraction
(but it might be an excellent low level object)
I'd hate not having a rows-and-tables view onto the database.
An Object-Relational-Mapper is nice to have of course, but I agree
with Piotr
that a traditional view onto the DB is a good start to built an ORM
on and I
think that the traditional view should also be available to the user
(it'll be
there internally anyway, at least for traditional relational
databases).
I fully agree, I probably did not express me clearly enough, a basic
table view is a must, but the ORM that one wants to realize might
influence how exactly the basic view looks like.
For example it would be nice if a basic row would also somehow be the
basic object of the ORM with a dynamic description, and automatically
specialized if the db description is available at compiletime.
As I had said before "the object level can influence the choice of the
best low level interface", this does not imply that a lower level
interface is not needed :).
Also: How are you gonna write queries with only the ORM view? Parse
your own
SQL-like-syntax that uses the Object type? Or have the SQL operators
as methods?
And then generate the apropriate SQL string?
What about differences in SQL-syntax between different databases?
What about tweaks that may be possible when you write the SQL
yourself and not
have it generated from your ORM?
No, being able to write the SQL-queries yourself and having a "low
level" view
(tables and rows, like it's saved in the DB) is quite important.
again I fully agree, but if we want to be able to store business logic
in objects that come from the database, and be able to express them
easily (for example like ruby does), can be very useful.
At the ORM level one should express at most simple queries, for more
complex stuff SQL is a must (there is no point to define another DSL
when SQL is already one (but having special methods with common
queries can be useful to more easily support non SQL dbs).
However: Since Piotr already seems to have much work done, maybe
Christian
Manning could polish Piotrs work (if necessary) and create a ORM on
top of it?
if accepted I definitely think that Piotrs and Christian will have to
coordinate their work
Oh, and just an Idea: Maybe something like LINQ is feasible for ORM?
So you can
write a query that includes local containers/ranges, remote
Databases (=> part
of it will internally be translated to SQL) and maybe even XML (but
that could
be added later once the std.xml replacement is ready)?
well simple queries, not sure if a full LINQ implementation is too
much to ask, but simple queries should be feasible.
Fawzi
