Re: [Firebird-net-provider] Expanding mapping abilities for EF
As nobody else replied I've added DNET-301 and DNET-302 tickets into
tracker. And I'll implement these later. It's breaking any existing
applications, so it shouldn't bother not interested people.
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Re: [Firebird-net-provider] Expanding mapping abilities for EF
On Sat, Mar 6, 2010 at 15:15, Jiri Cincura disk...@cincura.net wrote: As nobody else replied I've added DNET-301 and DNET-302 tickets into tracker. And I'll implement these later. It's breaking any existing applications, so it shouldn't bother not interested people. It's breaking any existing applications I guess this is a typo ^^ Have a nice weekend! -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Re: [Firebird-net-provider] Expanding mapping abilities for EF
On Sat, Mar 6, 2010 at 15:32, Markus Ostenried chef_...@gmx.net wrote:
On Sat, Mar 6, 2010 at 15:15, Jiri Cincura disk...@cincura.net wrote:
As nobody else replied I've added DNET-301 and DNET-302 tickets into
tracker. And I'll implement these later. It's breaking any existing
applications, so it shouldn't bother not interested people.
It's breaking any existing applications
I guess this is a typo ^^
Have a nice weekend!
Yep, I forgot the not. :)
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Re: [Firebird-net-provider] Expanding mapping abilities for EF
Somebody else?
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Re: [Firebird-net-provider] Expanding mapping abilities for EF
On Thu, Dec 31, 2009 at 01:55, Daniel Rail dan...@accra.ca wrote:
What happens if someone uses another type for bools? As an example, I
As far as there's a default conversion to .NET bool, it's OK.
usually use CHAR(1) with the values T and F. If it can be
This will not work. .NET recognizes True and False as string
representation of bool.
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.
Maybe this will work, if the string is valid for Guid ctor. But
there's couple of hacks in provider's code to recognize guids and
transparently work with it, and it's also checking charset. Anyway,
you can try it. Just use the GetGuid value.
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
Warnings around EF designer are handled by EF itself. I cannot do much here.
developer use that combination. And, if an error occurs in runtime,
then the developer will realize that it wont work.
OK. Every opinion counts.
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.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
[Firebird-net-provider] Expanding mapping abilities for EF
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?
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.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
Re: [Firebird-net-provider] Expanding mapping abilities for EF
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
