FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Statement...the pain.
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> DDBI
View previous topic :: View next topic  
Author Message
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Thu Jan 22, 2009 6:30 am    Post subject: Statement...the pain. Reply with quote

I had a look at the new version of Statement. It's hideously ugly. Any plans to fix that?

Specifically, I have to bind all the parameters at once, using variadics (or, well, fake variadics). I can't use :name: syntax (which isn't so important for short queries), and I can't bind one at a time (which is a killer).

I'm going to have to stay with 0.2.5 for the time being, if it even compiles with a modern D compiler.
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Thu Jan 22, 2009 2:00 pm    Post subject: Re: Statement...the pain. Reply with quote

dhasenan wrote:
I had a look at the new version of Statement. It's hideously ugly. Any plans to fix that?


Well, this is the first critcism I have heard on the topic, so there weren't any plans prior to me reading this post Smile Now however, I would love to hear some suggestions on how it should look Smile

dhasenan wrote:

Specifically, I have to bind all the parameters at once, using variadics (or, well, fake variadics). I can't use :name: syntax (which isn't so important for short queries), and I can't bind one at a time (which is a killer).


The reason for the somewhat less than perfect variadics sorta API, is the need for virtuality and ref kinda parameters. However, there is kinda plans to wrap this in an additional frontend using "new variadics", ie templates. It is somewhat unfortunate for the progress that I'm in the middle of my busiest year ever. when tango 0.99.8 is out, this'll be my sparetime focus again though.
Back to top
View user's profile Send private message
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Thu Jan 22, 2009 3:35 pm    Post subject: Reply with quote

Okay, I made myself understand this API, and it actually works very well for what I want to do with it. I think I actually couldn't find a solution better fit to ORM in D.
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Thu Jan 22, 2009 4:51 pm    Post subject: Reply with quote

w00t!
Back to top
View user's profile Send private message
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Sat Jan 24, 2009 8:49 pm    Post subject: Reply with quote

Okay, I'm looking into this further. With Statement, I can easily write queries and execute that return no results. I can easily write and execute queries that return one row. But I can't use it for queries that return multiple rows.

I can use MultiResultSupport.query and get a MultiResult back, but this doesn't help me -- I have to build query strings manually, which is neither efficient nor safe.

Suggestions?
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sun Jan 25, 2009 3:27 am    Post subject: Reply with quote

Sorry, are you saying it is impossible to get results with multiple rows? Or just inconvenient (which isn't good either of course).
Back to top
View user's profile Send private message
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Sun Jan 25, 2009 7:52 am    Post subject: Reply with quote

It's impossible to create a parameterized query that returns multiple rows. It is possible to create a query that returns multiple rows, but only through string catenation, not through parameters.

Additionally, the means of retrieving information from a MultiResult is entirely different from the means of retrieving information from a Statement. They should each offer a Row or a collection of Rows, and ideally you would be able to access the information in the same format as you insert it into the query.

Currently I'm binding parameters to a query by casting the object reference to a void**, dereferencing that, and taking slices of the result. This is why it's convenient that Statement takes a void*[] to bind parameters, and also with the void*[] to bind results, I can just use memcpy to get the values back into the object.
Back to top
View user's profile Send private message AIM Address
aaronc542



Joined: 22 May 2007
Posts: 35
Location: NJ, USA

PostPosted: Sun Jan 25, 2009 12:30 pm    Post subject: Reply with quote

Hey dhasenan,

Check out my fork of ddbi at github - http://github.com/aaronc/ddbi/ - I think it should have a lot of the functionality you're looking for esp. with multi-statements and binding parameters. If you take a time to understand it, you'll probably find it pretty robust. API Docs at - http://aaronc.github.com/ddbi. Don't bother with Sqlite right now - it's not stable. Mysql was working quite well last time I tested though.

Aaron
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sun Jan 25, 2009 4:09 pm    Post subject: Reply with quote

FWIW, there is an intention to avoid Aaron's need of a fork.
Back to top
View user's profile Send private message
aaronc542



Joined: 22 May 2007
Posts: 35
Location: NJ, USA

PostPosted: Sun Jan 25, 2009 4:51 pm    Post subject: Reply with quote

For convenience's sake, the most important API doc URL's to check out are:

http://aaronc.github.com/ddbi/dbi.DBI.html
http://aaronc.github.com/ddbi/dbi.model.Database.html
http://aaronc.github.com/ddbi/dbi.model.Result.html
Back to top
View user's profile Send private message
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Tue Jan 27, 2009 6:57 pm    Post subject: Reply with quote

aaronc: thanks, but in case I release this code, it's good if I stay with the official release. Easier for people to find and install.

I hope your fork makes it back to trunk soon, though -- it looks awesome.
Back to top
View user's profile Send private message AIM Address
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Tue Jan 27, 2009 6:59 pm    Post subject: Reply with quote

Ew news! There's no way in ddbi trunk to have a query where you bind parameters as well as results?
Back to top
View user's profile Send private message AIM Address
aaronc542



Joined: 22 May 2007
Posts: 35
Location: NJ, USA

PostPosted: Tue Jan 27, 2009 10:38 pm    Post subject: Reply with quote

Ok, I would like to make a decision fairly soon as to whether not this gets merged into the trunk - and if not what API changes need to be made. FYI, I believe this code is fairly stable - I currently have the sqlite backend passing all unittests as well. The API I feel is also quite pleasant and featureful...

I believe one point of contention is whether my decision to merge Database and Result was a good one - my opinion is that allocating a separate class structure for each result and each row returned is simple unnecessary esp. if we want a high performance system. Ok, so maybe it's unkosher, but I think it will be easier to use and more performant in the long run... Also, there could be a way to detach a given result set from the main Database connection instance if that were so desired. I know in Mysql though, having two result sets open is bad... Anyway, comments please. I know we'd all like a new DDBI soon...
Back to top
View user's profile Send private message
dhasenan



Joined: 03 Feb 2005
Posts: 73
Location: New York

PostPosted: Wed Jan 28, 2009 6:31 am    Post subject: Reply with quote

aaronc542 wrote:
I believe one point of contention is whether my decision to merge Database and Result was a good one - my opinion is that allocating a separate class structure for each result and each row returned is simple unnecessary esp. if we want a high performance system.


You're doing IPC and are worried about the cost of allocating an object?

Quote:
Ok, so maybe it's unkosher, but I think it will be easier to use and more performant in the long run... Also, there could be a way to detach a given result set from the main Database connection instance if that were so desired. I know in Mysql though, having two result sets open is bad... Anyway, comments please. I know we'd all like a new DDBI soon...


In mysql, you could keep track of the open result sets and throw an exception if someone tries opening one when there's already one open. But that's not a valid reason for uniting Database and Result, unless every database has this property. Even then, I'd prefer a statically allocated Result for each database.

You seem to have done the same thing for Statement. This is pretty confusing, seeing setParam() on Database.

Additionally, you don't allow anyone to bind anything without using strong typing, and you don't allow people to bind one argument to a Statement at a time. This means that I wouldn't be able to use Statement without incurring a huge overhead in terms of instantiated templates.

Currently, my putative ORM stuff is instantiating one function template per class plus one function template per field. Each of these functions is below ten lines. The overhead per class in terms of compilation time...well, 200 classes with three fields each take about eight seconds to compile on my machine with mappings, or two seconds without mappings. For comparison, some other template-heavy stuff I've done might crash under a similar load because the compiler ran out of memory.

Also, the templates that would be required to use your Statement are pretty ugly. Recursive templates to create string mixins and so forth.

If you had Tango-style variadic functions (that is, a variadic function, as well as a function that takes _arguments and _argptr), I could work with that quite well. While it's hard to support both variadics and your template approach at the same time, there is no real benefit to the template approach; all you really need to do is change a couple loops and change getBindType's `static if (is (T == sometype))` to `if (type == typeid(sometype))`.
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Wed Jan 28, 2009 11:32 am    Post subject: Reply with quote

aaronc542 wrote:
Ok, I would like to make a decision fairly soon as to whether not this gets merged into the trunk - and if not what API changes need to be made. FYI, I believe this code is fairly stable - I currently have the sqlite backend passing all unittests as well. The API I feel is also quite pleasant and featureful...


I certainly want DDBI to be at least as feature rich as your fork, and that as soon as possible.

Quote:

I believe one point of contention is whether my decision to merge Database and Result was a good one - my opinion is that allocating a separate class structure for each result and each row returned is simple unnecessary esp. if we want a high performance system. Ok, so maybe it's unkosher, but I think it will be easier to use and more performant in the long run... Also, there could be a way to detach a given result set from the main Database connection instance if that were so desired. I know in Mysql though, having two result sets open is bad... Anyway, comments please. I know we'd all like a new DDBI soon...


After giving this more thought, I agree with dhasenan (if I understand him correctly) and do not think the merge helps. I agree that the current version in trunk probably over allocates a bit, but a small test I did suggests that it doesn't really make a dent in 'top'. I believe (for the non-statement case) that the majority of the allocation happens in the dbms library in any case.

That there in most cases is a one-to-one mapping between database and result isn't in itself a good enough reason to merge.

I can see that dhasenan also seems to be coming over usability issues with both current approaches.

In the end - I do find the fork approach somewhat difficult to work with because it is too tedious to produce proper diffs, so in general I only look at the API until I have an idea of what should be implemented.

And to end that Razz : I've been very busy for the last couple of months, and although the situation is improving somewhat, I cannot throw in many hours per week just yet, so please show a bit patience Smile One way to ease the process for me, would be to create actual patches against DDBI svn.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DDBI All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group