Hi Jon,
Thanks for your reply.
Not sure I'll commit to being the maintainer, but I'll lurk around
and help out when I can. :-)
As I alluded to in my other post, my changes didn't exactly work
properly anyway! When using a lambda expression, the Enum value was
being replaced with a numeric constant in the expression tree. I
tried to work out where this was being done, but got a bit lost.
Would this actually be done in DBLinq? In the end changing the
generated Enums seemed like the best result vs. effort pay off.
If you agree, then I'll happily look at changing DBMetal and
providing some patches.
Cheers,
Matt.
On Sep 11, 7:22 pm, Jonathan Pryor <[email protected]> wrote:
> Below...
>
> On Thu, 2009-08-13 at 12:33 -0700, Matt Dargavel wrote:
> > I've checked out the code to DbLinq today and started experimenting
> > with using it to access a MySql database with one of our .NET / Mono
> > based products and have come across a couple of issues when using Enum
> > fields.
>
> Two questions:
>
> 1. MySQL support has no maintainers. Are you interested in becoming the
> MySQL maintainer? :-D
>
> 2. Where do your changes occur?
>
> DbLinq (as you might have noticed) is split up into multiple assemblies:
> DbLinq.dll (core) and DbLinq.VENDOR.dll (e.g. DbLinq.MySql.dll,
> DbLinq.Sqlite.dll, etc.).
>
> If your changes occur only in DbLinq.MySql.dll (e.g. your code only
> changes files within src/DbLinq.MySql), then it can't impact the core
> code.
>
> If it does require changes to core code, we may want to refactor things
> so that this particular piece of logic can be done in the vendor code,
> if appropriate.
>
> > The first was that DBLinq was trying to convert the returned Enum
> > field value to an integer, but this was failing as MySql returns the
> > value as a string representation of the Enum value name unless you do
> > something like SELECT enum_field+0 .. which then returns the integer
> > value.
>
> > I fixed this by making a couple of small changes to DataRecordReader
> > so that it uses some existing functions to Enum.Parse the returned
> > string when the return type is an enum.
>
> Yeah, that's a core type. Changing this for all databases is likely a
> very bad idea. We'll need to add some sort of mechanism so that the
> vendor-specific code can be involved here.
>
> > The second problem was when inserting (or presumably updating) a
> > record with an Enum field in the db I got a truncated data error. The
> > problem here was that the generated class file creates an enum with
> > the same enum members, but in C# the values start at 0, in MySql they
> > start at 1.
>
> > I fixed this by changing ObjectInputParameterExpression.GetValue so
> > that if the ValueType is an Enum it converts the value to a string
> > (the enum value name) before returning it. I guess the other way to
> > do it would be to change the Enum generation (maybe to include an
> > Unknown value first?).
>
> Also core, same result. We need to create a call-out to vendor code.
>
> Now, how would such a "call-out" work?
>
> Vendor assemblies provide a SqlProvider sub-class, which is used from
> various places. For example,
> DbLinq.Data.Linq.Sugar.Implementation.SqlBuilder calls
> SqlProvider.GetTranslator() so that vendor code can perform "high-level"
> manipulation of expression trees. You should be able to follow the same
> pattern to insert additional calls to the vendor's SqlProvider, allowing
> for DB-specific changes to occur.
>
> Thanks,
>
> - Jon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---
