Call for Discussion: dbi.Row

cryogen · Joined: 05 Jan 2007 Posts: 4

Hmm, where did you get the idea Pg cant get type information?

cryogen · Joined: 05 Jan 2007 Posts: 4

MyronAlexander · Joined: 11 Jan 2007 Posts: 9

Hello.

I'm very new to D and I am a Java programmer. How influenced by the JDBC is the new Row.d?

I ask this question as the Java team have spent a considerable amount of time working on this problem and it may be useful to use their work as a basis for understanding the problem-space. The Java team have not implemented the perfect mechanism, and it may not take advantage of the facilities that D provides, but it does work.

Regards,

Myron.

brad · Posted: Thu Jan 11, 2007 3:56 pm Post subject:

svanleent · Joined: 25 Sep 2004 Posts: 53

Though it is nice to have get{name} functions, there should be a way to retrieve the data in a raw format, as it is. This is important for databases with specialisations such as GIS databases. This way, the row can be bound to an extension object, which is able to handle these kinds of data without to many problems.
_________________
How C++ became ancient

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

With the current Row implementation, I have to hack your source to see which columns a query retrieved. This really hampers library usage of Rows. For usability, you can either make the fields in Row public (my ten-second hack did just that), or you can provide a .length property and get accessors for names and types according to index.

I can't work around this problem by trying to get a value by column name and handling errors gracefully because Row doesn't handle errors gracefully. I'd have to catch an array bounds error, and I'm not sure that's possible. It would at least be a very ugly way of doing it.

larsivi · Posted: Sun May 11, 2008 10:34 am Post subject:

I will be working on DDBI (and rows) in the near future, and so this thread will be an important pointer on the direction.

dhasenan, could you provide a more explicit hint on what your hack is? And maybe an example of what you are doing?

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

I'm trying to map a class to a database table. Usually the mapping information would be duplicated in a few methods in the appropriate Repository class. For instance, your UserRepository would know how to extract a User from a Row, and it would know how to add fields from a User to a Statement for a given query. If you wanted to, you could also have the UserRepository contain enough information to create the table from scratch where necessary.

This is redundant. I have a couple templates and some classes thrown together so I can write my class as:

Zaighster · Joined: 24 Sep 2008 Posts: 1 Location: Sydney, Australia

I'm joining this discussion a little late, perhaps too late, but I wan't to say this anyway.

My impression is that some of the functionality being discussed here is going beyond the scope of the project.

If I'm not mistaken, the purpose of the project is to hide the database implementation. So the library should be kept to serving that purpose, and functionality that does not directly serve that purpose should be implemented elsewhere.

This is particularly true for functionality that cannot be applied to all databases. The case in point being the handling of PostgreSQL. If you make it so that PostgreSQL databases appear differently to the user to other databases, then you completely defeat the purpose of the project.

After all, remember the Unix credo - Everything should do just one thing well.

Regards

larsivi · Posted: Sun Nov 30, 2008 3:23 am Post subject:

It has taken some time, but I started to commit the "new" DDBI a little while ago. Sofar, it has MySQL support in there, and I have SQLite support mostly done on my disk.

The question of how to get the various types from Row is sortof not yet resolved - meaning I can implement the suggestions used here, but ...

I currently have commented out functions like

void fetch(inout int val);

from the interface, but I think that will be what I will add in. There is of course still the getInt/etc approach to look at, but I won't put in both.

An additional idea I had which may or may not be helpful, is to use Variant - but unless the user knows what is expected to come out of it, the user will have to check which type it holds.

When this is said about Row, prepared statements will handle this differently - typically because at least some databases handles them differently. When executing the statement, you pass along an array of the variables into which the results will be placed - this routine will do the necessary type matching internally. Thus when the statement is done executing, you will have the data where you want them.

Regarding Zaighster's comments - some of the implementations will support functionality not in the others - but as long as possible, this will done through providing feature enabling interfaces, and a feature enabling interface. That there is a potential duality to this is because some features requires extra API functions, some features just needs to be enabled internally in the RDBMS and some (like Multi result support) needs both.

Anyway, feel free to check out trunk and see what is there - I want feedback Smile