Thread: [Mysql-cocoa-users] numOfRows
Brought to you by:
sergecohen
|
From: Famille GOUREAU-S. <sui...@wa...> - 2002-05-22 20:27:24
|
Hi,
does anybody wish to solve a new problem ? (many thanks to Serge for
previous one :) )
Here is the software :
NSLog (@"query : %@",chaine) ; // present the query
result = [connection queryString: chaine]; // send the query
NSLog (@"numOfRows : %d", [result numOfRows]) ; // should give the
number of rows matching the query
while (chaine = [result fetchRowAsDictionary]) // This loop
will test for every row in the query up to the last one
{
NSLog(@"descriptif : %@\n", [chaine objectForKey: @"descriptif"]);
compteurI++ ;
}
NSLog (@"nombre d'enreg correspondants : %d", compteurI) ; //How many
rows are in the response
NSLog(@"descriptif : %@\n", [chaine objectForKey: @"descriptif"]);
And here is the result :
2002-05-22 22:19:17.860 Gestionnaire stock[989] query : select
descriptif, fournisseur from stock where reference like 'M07%' and
fournisseur = 'ABC' ;
2002-05-22 22:19:17.909 Gestionnaire stock[989] numOfRows : 0
2002-05-22 22:19:17.910 Gestionnaire stock[989] descriptif : Marionnette
chat gri
2002-05-22 22:19:17.910 Gestionnaire stock[989] descriptif : Marionnette
chat noi
2002-05-22 22:19:17.910 Gestionnaire stock[989] nombre d'enreg
correspondants : 2
2002-05-22 22:19:17.911 Gestionnaire stock[989] descriptif : (null)
The problem is that a result contain X rows (attested by "nombre d'enreg
correspondants : 2" and by a manual test under unix terminal) and that
the numOfRows function always reply by a 0.
An idea ?
Thanks.
Camille
|
|
From: Serge C. <co...@em...> - 2002-05-23 09:52:23
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Camille;=0D
=0D
I guess the problem comes from the type of the result of [result =0D
numOfRows] is my_ulonglong where as %d in the string waits for an int. =0D=
Try :=0D
NSLog (@"numOfRows : %d", (int)[result numOfRows])=0D
=0D
(that's a guess, don't take it for sure, and by the way I'd be =0D
interested in the issue).=0D
=0D
just one remark:=0D
in the line : NSLog (@"query : %@",chaine) ; chaine is obviously of type =
=0D
NSString*=0D
in the line : chaine =3D [result fetchRowAsDictionary] ; chaine is now =
of =0D
type NSDictionary*=0D
=0D
I guess you have decalred chaine as type id, which fits both object =0D
pointers, but you'd better of having different names still.=0D
=0D
=0D
Serge.=0D
=0D
Le mercredi 22 mai 2002, =C3=A0 10:25 PM, Famille GOUREAU-SUIGNARD a =
=C3=A9crit :=0D
=0D
> Hi,=0D
>=0D
> does anybody wish to solve a new problem ? (many thanks to Serge for =0D=
> previous one :) )=0D
>=0D
> Here is the software :=0D
>=0D
> NSLog (@"query : %@",chaine) ; =
// present the query=0D
> result =3D [connection queryString: chaine]; =
// send the query=0D
> NSLog (@"numOfRows : %d", [result numOfRows]) ; // should give =
the =0D
> number of rows matching the query=0D
> while (chaine =3D [result fetchRowAsDictionary]) // This =
loop =0D
> will test for every row in the query up to the last one=0D
> {=0D
> NSLog(@"descriptif : %@\n", [chaine objectForKey: @"descriptif"]);=0D=
> compteurI++ ;=0D
> }=0D
> NSLog (@"nombre d'enreg correspondants : %d", compteurI) ; //How =
many =0D
> rows are in the response=0D
> NSLog(@"descriptif : %@\n", [chaine objectForKey: @"descriptif"]);=0D
>=0D
> And here is the result :=0D
>=0D
> 2002-05-22 22:19:17.860 Gestionnaire stock[989] query : select =0D
> descriptif, fournisseur from stock where reference like 'M07%' and =0D
> fournisseur =3D 'ABC' ;=0D
> 2002-05-22 22:19:17.909 Gestionnaire stock[989] numOfRows : 0=0D
> 2002-05-22 22:19:17.910 Gestionnaire stock[989] descriptif : =0D
> Marionnette chat gri=0D
> 2002-05-22 22:19:17.910 Gestionnaire stock[989] descriptif : =0D
> Marionnette chat noi=0D
> 2002-05-22 22:19:17.910 Gestionnaire stock[989] nombre d'enreg =0D
> correspondants : 2=0D
> 2002-05-22 22:19:17.911 Gestionnaire stock[989] descriptif : (null)=0D
>=0D
> The problem is that a result contain X rows (attested by "nombre =0D
> d'enreg correspondants : 2" and by a manual test under unix terminal) =0D=
> and that the numOfRows function always reply by a 0.=0D
>=0D
> An idea ?=0D
>=0D
> Thanks.=0D
>=0D
> Camille=0D
>=0D
>=0D
> _______________________________________________________________=0D
>=0D
> Don't miss the 2002 Sprint PCS Application Developer's Conference=0D
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm=0D=
>=0D
> _______________________________________________=0D
> Mysql-cocoa-users mailing list=0D
> Mys...@li...=0D
> https://lists.sourceforge.net/lists/listinfo/mysql-cocoa-users=0D
>=0D
>=0D
- ----------------------------------------------------=0D
Serge Cohen=0D
=0D
GPG Key ID: 1024D/69B1D346=0D
- ----------------------------------------------------=0D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
iD8DBQE87Lx5Mygj1Wmx00YRAtFtAKCNKJb6ErX7GqdvOtL6gtUrXKo2yQCeJzZg
1aWeS1wj/5rpVdWKHTebjq8=3D
=3DUOxY
-----END PGP SIGNATURE-----
|
|
From: Bertrand M. <bma...@wa...> - 2002-05-24 16:17:30
|
Hi serge, I've had a look at the implementation of fetchRowAsDictionary and fetchRowAsArray : they look quite similar and are both quite long due to the typing process. This means they are a pain to maintain. I believe there could be some code reuse. So I suggest a different approach. In PEAR DB, we use a generic method to do the fetch work, the result is set according to a specified fetch mode. For instance it could be: fetchRowWithMode:(unsigned int)mode with constants like: DB_FETCHMODE_ORDERED (for array) = 0 DB_FETCHMODE_ASSOC (for dictionary) = 1 DB_FETCHMODE_OBJECT (column data as object properties) = 2 DB_FETCHMODE_FLIPPED (multidimensional array: column name => all rows) = 3 ... which would give us: [result fetchRowWithMode:DB_FETCHMODE_ASSOC]; instead of [result fetchRowAsDictionary]; Tell me what you think about that. Next, I think we could implement a few methods that are very handy when it comes to quickly programming. They are: - (id) getOne:(NSString *) query; getOne takes a query string as parameter and returns the first field from the first row. It initialises and dealloc the SMySQLResult itself so the developer does not need to take care of that. Ex: [mConnection getOne:@"select password from users where username='user1'"]; It should return nil if no result is found. - (id) getRow:(NSString *) query withMode:(unsigned int) mode; getRow will return an NSArray or a NSDictionary containing the first row of the result according to what mode it is given. Ex: [mConnection getRow:@"select * from users where username='user1'" withMode:]; It should return nil if no result is found. - (id) getAll:(NSString *) query withMode:(unsigned int) mode; Same as getRow but will fill a multidimensional NSArray with all the rows. [mConnection getAll:@"select * from users" withMode:DB_FETCHMODE_ASSOC]; It should return nil if no result is found. - (id) getCol:(NSString *) query withColIndex:(unsigned int) col; Will fetch a column (by its colunm index starting from 0) from a result set and return it as an NSArray. Ex: [mConnection getCol:@"select * from users" withColIndex:0]; It should return nil if no result is found. Tell me what you think of that too. I don't think it will be too difficult to code. Take care, Bertrand Mansion Mamasam |
|
From: John G. <jo...@jl...> - 2002-05-27 18:36:33
|
I'd like to add my comments as support to those of Bertrand, His proposal to make a single piece of code seems sensible, HOWEVER I would add that I think it may make sense to keep the original methods and wrap them around the new calls, this would be a benefit to a novice user, but would keep compatability with existing C API's. I know it is quite simple to add a fetchmode command, but it does tend to make code slightly less readable, also in addition I prefer to use wrapper classes that return a specified object (NSArray, OR NSDictionary etc.) so that the compiler can issue warnings that makes debugging easier than relying on (id) types - ALTHOUGH I would support this wholeheartedly for the generic function. I also like the quick queries proposed, and have actually implemented something similar within my code to make programming quicker - ie. simpleQuery() which queries, grabs all and returns. I have a possible new request to throw into the pot following some work I did last week. I am working on a lightweight content management system and have been producing queries that in turn produce additional queries. What would be useful for me is to return all my results as the strings that are returned in the SQL. For example: "SELECT PAGEID, TITLE FROM PAGES" where PAGEID is an INT and TITLE is a string. What would be useful is if I can return an NSDictionary object that has string objects for both PAGEID and TITLE, since I am simply passing the PAGEID back into and SQL query at some point in the future. I was browsing the library code and this looks like a case of simply skipping the typing process. So maybe this is something else that could be built into a generic version of the query code with an extra Fetch mode flag (maybe RETURN_MODE) anyway just some feedback JOhn On Friday, May 24, 2002, at 04:19 PM, Bertrand Mansion wrote: > Hi serge, > > I've had a look at the implementation of fetchRowAsDictionary and > fetchRowAsArray : they look quite similar and are both quite long due > to the > typing process. This means they are a pain to maintain. I believe there > could be some code reuse. > > So I suggest a different approach. In PEAR DB, we use a generic method > to do > the fetch work, the result is set according to a specified fetch mode. > For > instance it could be: > > fetchRowWithMode:(unsigned int)mode > > with constants like: > DB_FETCHMODE_ORDERED (for array) = 0 > DB_FETCHMODE_ASSOC (for dictionary) = 1 > DB_FETCHMODE_OBJECT (column data as object properties) = 2 > DB_FETCHMODE_FLIPPED (multidimensional array: column name => all > rows) = 3 > ... > > which would give us: > > [result fetchRowWithMode:DB_FETCHMODE_ASSOC]; > instead of [result fetchRowAsDictionary]; > > Tell me what you think about that. > > > Next, I think we could implement a few methods that are very handy when > it > comes to quickly programming. They are: > > - (id) getOne:(NSString *) query; > > getOne takes a query string as parameter and returns the first field > from > the first row. It initialises and dealloc the SMySQLResult itself so the > developer does not need to take care of that. Ex: > [mConnection getOne:@"select password from users where > username='user1'"]; > It should return nil if no result is found. > > - (id) getRow:(NSString *) query withMode:(unsigned int) mode; > > getRow will return an NSArray or a NSDictionary containing the first > row of > the result according to what mode it is given. Ex: > [mConnection getRow:@"select * from users where username='user1'" > withMode:]; > It should return nil if no result is found. > > - (id) getAll:(NSString *) query withMode:(unsigned int) mode; > > Same as getRow but will fill a multidimensional NSArray with all the > rows. > [mConnection getAll:@"select * from users" withMode:DB_FETCHMODE_ASSOC]; > It should return nil if no result is found. > > - (id) getCol:(NSString *) query withColIndex:(unsigned int) col; > > Will fetch a column (by its colunm index starting from 0) from a result > set > and return it as an NSArray. Ex: > [mConnection getCol:@"select * from users" withColIndex:0]; > It should return nil if no result is found. > > Tell me what you think of that too. I don't think it will be too > difficult > to code. > > Take care, > > Bertrand Mansion > Mamasam > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Mysql-cocoa-users mailing list > Mys...@li... > https://lists.sourceforge.net/lists/listinfo/mysql-cocoa-users > |
|
From: Serge C. <co...@em...> - 2002-05-28 11:24:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi;=0D =0D Indeed I'm sorry to answer that late to both Bertrand and you.=0D =0D I definetly agrees with the maintenance problem of having two method =0D doing nearly the same things. In the mean time I'm coming from C, C++ =0D= and I think typing object is really important to have readable code, so =0D= I'd like to think a bit of all the pros and cons for the propositions =0D= you've made, and give a definitive answer in a couple of days.=0D =0D About the "Fast query methods". I agree that they can be of great use =0D= for fast programming, in the mean time the idea of an object is to have =0D= the "proper" interface: not to small, but not clutered by a lot of =0D redundant method. Maybee we can put these in a category, so that the =0D class interface by itself is limited to the functionalyties of the C API = =0D we rely on.=0D What do you think of this choice?=0D =0D For the method returning every things as string, the point is that you =0D= might want a special format from one user to the other, so how would you = =0D pass this kind of arguments to the function?=0D The solution I think about would something like a Dictionary (or Array) =0D= containing the format for each column, but then again do you gain much?=0D= =0D =0D Serge.=0D =0D NB: I'm very happy to get new ideas and comments for the SMySQL =0D framework here. I might be a bit slow to answer from time to time; this =0D= is only due to the limited amount of time I can spend on this project =0D= (I'm writing my PhD in Biology for the moment). So PLEASE, don't be =0D discouraged by my delayed answer.=0D =0D Le lundi 27 mai 2002, =C3=A0 09:36 , John Guy a =C3=A9crit :=0D =0D > I'd like to add my comments as support to those of Bertrand,=0D >=0D > His proposal to make a single piece of code seems sensible, HOWEVER I =0D= > would add that I think it may make sense to keep the original methods =0D= > and wrap them around the new calls, this would be a benefit to a = novice =0D > user, but would keep compatability with existing C API's.=0D >=0D > I know it is quite simple to add a fetchmode command, but it does tend = =0D > to make code slightly less readable, also in addition I prefer to use =0D= > wrapper classes that return a specified object (NSArray, OR =0D > NSDictionary etc.) so that the compiler can issue warnings that makes =0D= > debugging easier than relying on (id) types - ALTHOUGH I would support = =0D > this wholeheartedly for the generic function.=0D >=0D > I also like the quick queries proposed, and have actually implemented =0D= > something similar within my code to make programming quicker - ie. =0D > simpleQuery() which queries, grabs all and returns.=0D >=0D > I have a possible new request to throw into the pot following some =0D= > work I did last week. I am working on a lightweight content management = =0D > system and have been producing queries that in turn produce additional = =0D > queries. What would be useful for me is to return all my results as = the =0D > strings that are returned in the SQL. For example:=0D >=0D > "SELECT PAGEID, TITLE FROM PAGES" where PAGEID is an INT and TITLE is = a =0D > string. What would be useful is if I can return an NSDictionary object = =0D > that has string objects for both PAGEID and TITLE, since I am simply =0D= > passing the PAGEID back into and SQL query at some point in the = future. =0D > I was browsing the library code and this looks like a case of simply =0D= > skipping the typing process. So maybe this is something else that = could =0D > be built into a generic version of the query code with an extra Fetch =0D= > mode flag (maybe RETURN_MODE)=0D >=0D > anyway just some feedback=0D >=0D > JOhn=0D >=0D > On Friday, May 24, 2002, at 04:19 PM, Bertrand Mansion wrote:=0D >=0D >> Hi serge,=0D >>=0D >> I've had a look at the implementation of fetchRowAsDictionary and=0D >> fetchRowAsArray : they look quite similar and are both quite long due = =0D >> to the=0D >> typing process. This means they are a pain to maintain. I believe = there=0D >> could be some code reuse.=0D >>=0D >> So I suggest a different approach. In PEAR DB, we use a generic = method =0D >> to do=0D >> the fetch work, the result is set according to a specified fetch = mode. =0D >> For=0D >> instance it could be:=0D >>=0D >> fetchRowWithMode:(unsigned int)mode=0D >>=0D >> with constants like:=0D >> DB_FETCHMODE_ORDERED (for array) =3D 0=0D >> DB_FETCHMODE_ASSOC (for dictionary) =3D 1=0D >> DB_FETCHMODE_OBJECT (column data as object properties) =3D 2=0D >> DB_FETCHMODE_FLIPPED (multidimensional array: column name =3D> all =0D= >> rows) =3D 3=0D >> ...=0D >>=0D >> which would give us:=0D >>=0D >> [result fetchRowWithMode:DB_FETCHMODE_ASSOC];=0D >> instead of [result fetchRowAsDictionary];=0D >>=0D >> Tell me what you think about that.=0D >>=0D >>=0D >> Next, I think we could implement a few methods that are very handy =0D= >> when it=0D >> comes to quickly programming. They are:=0D >>=0D >> - (id) getOne:(NSString *) query;=0D >>=0D >> getOne takes a query string as parameter and returns the first field =0D= >> from=0D >> the first row. It initialises and dealloc the SMySQLResult itself so =0D= >> the=0D >> developer does not need to take care of that. Ex:=0D >> [mConnection getOne:@"select password from users where =0D >> username=3D'user1'"];=0D >> It should return nil if no result is found.=0D >>=0D >> - (id) getRow:(NSString *) query withMode:(unsigned int) mode;=0D >>=0D >> getRow will return an NSArray or a NSDictionary containing the first =0D= >> row of=0D >> the result according to what mode it is given. Ex:=0D >> [mConnection getRow:@"select * from users where username=3D'user1'"=0D= >> withMode:];=0D >> It should return nil if no result is found.=0D >>=0D >> - (id) getAll:(NSString *) query withMode:(unsigned int) mode;=0D >>=0D >> Same as getRow but will fill a multidimensional NSArray with all the =0D= >> rows.=0D >> [mConnection getAll:@"select * from users" =0D >> withMode:DB_FETCHMODE_ASSOC];=0D >> It should return nil if no result is found.=0D >>=0D >> - (id) getCol:(NSString *) query withColIndex:(unsigned int) col;=0D >>=0D >> Will fetch a column (by its colunm index starting from 0) from a =0D >> result set=0D >> and return it as an NSArray. Ex:=0D >> [mConnection getCol:@"select * from users" withColIndex:0];=0D >> It should return nil if no result is found.=0D >>=0D >> Tell me what you think of that too. I don't think it will be too =0D >> difficult=0D >> to code.=0D >>=0D >> Take care,=0D >>=0D >> Bertrand Mansion=0D >> Mamasam=0D >>=0D >>=0D >>=0D >>=0D >>=0D >>=0D >> _______________________________________________________________=0D >>=0D >> Don't miss the 2002 Sprint PCS Application Developer's Conference=0D >> August 25-28 in Las Vegas -- = http://devcon.sprintpcs.com/adp/index.cfm=0D >>=0D >> _______________________________________________=0D >> Mysql-cocoa-users mailing list=0D >> Mys...@li...=0D >> https://lists.sourceforge.net/lists/listinfo/mysql-cocoa-users=0D >>=0D >=0D >=0D - ----------------------------------------------------=0D Serge Cohen=0D =0D GPG Key ID: 1024D/69B1D346=0D - ----------------------------------------------------=0D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE882lpMygj1Wmx00YRApZ8AJwNh3EfAWEyb4Jxi4Js4Vx6Q+xJswCgpLJh cKctum4VQLqAk7pfSiwHtog=3D =3DD3+o -----END PGP SIGNATURE----- |
|
From: Bertrand M. <bma...@wa...> - 2002-05-28 11:51:18
|
le 28/05/02 13:26, Serge Cohen =E0 co...@em... a =E9crit=A0: > Hi; >=20 >=20 >=20 > Indeed I'm sorry to answer that late to both Bertrand and you. >=20 > I definetly agrees with the maintenance problem of having two method > doing nearly the same things. In the mean time I'm coming from C, C++ > and I think typing object is really important to have readable code, so > I'd like to think a bit of all the pros and cons for the propositions > you've made, and give a definitive answer in a couple of days. Take your time, there's no hurry. :-) > About the "Fast query methods". I agree that they can be of great use > for fast programming, in the mean time the idea of an object is to have > the "proper" interface: not to small, but not clutered by a lot of > redundant method. Maybee we can put these in a category, so that the > class interface by itself is limited to the functionalyties of the C API > we rely on. > What do you think of this choice? A category would be fine for me. > For the method returning every things as string, the point is that you > might want a special format from one user to the other, so how would you > pass this kind of arguments to the function? > The solution I think about would something like a Dictionary (or Array) > containing the format for each column, but then again do you gain much? This looks a bit difficult and I don't know if it will be used a lot. I see there is a stringValue method in NSNumber and an intValue in NSString= . Most of the time, you know what your field type is, and if not, you can always check with fetchTypesAsDictionary of SMySQLResult. It isn't complex to convert from int to NSString on a per field basis but it will probably require a lot of test to create a general translation method. Don't you think ? Anyway, feel free to add it if you really need it. > Serge. >=20 >=20 >=20 > NB: I'm very happy to get new ideas and comments for the SMySQL > framework here. I might be a bit slow to answer from time to time; this > is only due to the limited amount of time I can spend on this project > (I'm writing my PhD in Biology for the moment). So PLEASE, don't be > discouraged by my delayed answer. No worries. Take care, Bertrand Mansion Mamasam PS : I don't know why, but I always receive you messages with 2 newlines instead of just one as usual. This makes reading them uncomfortable. It probably comes from the settings of your mail client ? Just to let you know... |