[Mysql-cocoa-users] (no subject)

[Serge C. <co...@em...>]

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