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

Call for Discussion: dbi.Row
Goto page Previous  1, 2
 
Post new topic   Reply to topic     Forum Index -> DDBI
View previous topic :: View next topic  
Author Message
cryogen



Joined: 05 Jan 2007
Posts: 4

PostPosted: Wed Jan 10, 2007 9:34 am    Post subject: Reply with quote

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

Quote:

PQftype

Returns the data type associated with the given column number. The integer returned is the internal OID number of the type. Column numbers start at 0.

Oid PQftype(const PGresult *res,
int column_number);

You can query the system table pg_type to obtain the names and properties of the various data types. The OIDs of the built-in data types are defined in the file src/include/catalog/pg_type.h in the source tree.


Said file contains defines which cover pretty much every type you can think of.
Back to top
View user's profile Send private message
cryogen



Joined: 05 Jan 2007
Posts: 4

PostPosted: Wed Jan 10, 2007 9:54 am    Post subject: Reply with quote

Code:

Index: dbi/pg/PgResult.d
===================================================================
--- dbi/pg/PgResult.d   (revision 44)
+++ dbi/pg/PgResult.d   (working copy)
@@ -48,7 +48,9 @@
                }
                Row r = new Row();
                for (int a = 0; a < numFields; a++) {
-                       r.addField(strip(asString(PQfname(results, a))), strip(asString(PQgetvalue(results, index, a))), "", 0);
+                       r.addField(strip(asString(PQfname(results, a))),
+          strip(asString(PQgetvalue(results, index, a))), "",
+          PQftype(results, a));
                }
                index++;
                return r;

Back to top
View user's profile Send private message
MyronAlexander



Joined: 11 Jan 2007
Posts: 9

PostPosted: Thu Jan 11, 2007 3:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Thu Jan 11, 2007 3:56 pm    Post subject: Reply with quote

MyronAlexander wrote:
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.

I would guess that the new Row object, and DDBI in general, will end up very close to JDBC, much closer than it is currently.

get{Type}() methods
Statements, CallableStatements even??
URL connection strings

BA
Back to top
View user's profile Send private message
svanleent



Joined: 25 Sep 2004
Posts: 53

PostPosted: Thu Feb 07, 2008 4:11 am    Post subject: Specialist Database Support Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger MSN Messenger
dhasenan



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

PostPosted: Sun May 11, 2008 8:38 am    Post subject: Reply with quote

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.
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 May 11, 2008 10:34 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
dhasenan



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

PostPosted: Sun May 11, 2008 3:14 pm    Post subject: Reply with quote

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:
Code:

class User
{
   mixin(db_property!(int, "key", "id"));
   mixin(db_property!(char[], "name"));
   mixin(db_property!(char[], "address"));
}


(I haven't gotten around to automating anything inside the Repositories other than filling in the requested fields in a Statement and getting a mapped object from a Row, and that of course doesn't support relationships between mapped classes. But it's a start.)

I can still do everything I need to with the current implementation of Row; it's just that anything missing from the Row will result in an ArrayBoundsError and anything that's in the Row but missing from the mapping is silently ignored. In short, there is no possibility of validation.
Back to top
View user's profile Send private message AIM Address
Zaighster



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

PostPosted: Wed Sep 24, 2008 8:59 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
larsivi
Site Admin


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

PostPosted: Sun Nov 30, 2008 3:23 am    Post subject: Reply with quote

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
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 Previous  1, 2
Page 2 of 2

 
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