Hi, At December-30-09, 2:40 PM, Jiri Cincura wrote:
> Hi *, > I was thinking about supporting broader variety of datatypes (from > .NET) in EF for mapping. We already had a request for direct guid > support and since beginning we have (manual) support for bools. > Unfortunately neither of these is available directly in FB, hence > there's set of "standard" workarounds like char(16) octets for guid. > And as we started supporting features not available in FB directly > through "autoincrement" field via #PK_GEN# in comment, I would like to > propose similar way for bool and guid. I don't like the way of > guessing - char(16) octets => guid etc. It may work in 99 percent > cases but, sooner or later you hit the wall with bad guess. So my > propose is to "override" the datatype of column reported by provider > for EF by two new magic keywords. For guids it'll be #GUID# and for > bools #BOOL#. > What I'm not sure about is whether do check for the datatype as well. > Like smallint && #BOOL# is bool, but timestamp && #BOOL# is still > timestamp. I'm more for blindly using the comment and leave the > thinking to developer. Why? Because for i.e. bool you can have > smallint, int, bigint and maybe decimal if you're brave enough. For > guids with triggers and views maybe some crazy types. This shouldn't > create any hidden places with potential error. As if the thinking will > be wrong with first let's say insert you'll get an error. But that's > only my view. > Any comments, thoughts? What happens if someone uses another type for bools? As an example, I usually use CHAR(1) with the values "T" and "F". If it can be configurable, with a default of SMALLINT, it would be even better. And, I could almost say the same for GUIDs, as some might be storing them in a VARCHAR(32), in another charset than OCTET. I currently use ECO and the GUID field is stored in a VARCHAR(32) UTF-8 field. And, don't try to automatically map to those types, because it's possible that someone uses a SMALLINT field as an actual SMALLINT, not a boolean. I could probably say the same for CHAR(16) OCTET, as you might be suspecting for that other 1%, where the assumption might be wrong. I would suggest, if it's possible, to simply give a warning to the developer that #BOOL# and TIMESTAMP don't match, but still let the developer use that combination. And, if an error occurs in runtime, then the developer will realize that it wont work. -- Best regards, Daniel Rail Senior Software Developer ACCRA Solutions Inc. (www.accra.ca) ACCRA Med Software Inc. (www.filopto.com) ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
