[Mono-dev] Linq to Sql Start

[Kevin Kubasik]

Hey, I totally get that, I really hadn't meant for there to be sooo
much lumped into that patch. I'm going through and breaking the task
down into smaller utility classes (some public, some private) and once
the framework for them is in place, I can seriously examin the grander
scheme.

Anyways, this e-mail is 3-fold
1) I have attached a neat and clean and pretty patch that does the following:
    * Implements QueryCompiler near 100%
    * Adds ChangeSet to the build, and adds a nearly complete implementation
    * ChangeLog and Build infrastructure for both of these classes
    * I filed a bug so the patch wouldn't get lost, its here at:
https://bugzilla.novell.com/show_bug.cgi?id=327018 (Yeah, its kinda a
dumb bug, but its a random subset of work I guess...)

2) You might notice that I did not include any mention of Unit Tests
(implying untested code, a big no-no!) I do have tests, but most of
them still revolve around query expressions using the generated
NorthWindDataContext, and I am unsure of how exactly to proceed.
Miguel had mentioned writing a tool to generate the mappings code
(which is on the TODO at some point, but that task is almost
impossible to reasonably test before we have working Expression
parsing and accurate execution (in terms of time, order, and source).
For my own experimentation, discovery and testing, this setup
(augmented by the VS debugger) works quite well for determining the
behavior of API's.

However, there is far too much overhead at the moment to make that
part of the official test suite. I know this is probably just my
inexperience with not only Nunit, but the Test driven development
model in general. Since the whole System.Data.Linq namespace is
currently test-less, I don't know if we would hold off on new code
until that issue has been taken care of, or we can put it off until
theres a more cohesive framework to test, or what. I'll be busy enough
 collating things and completing full classes instead of just 1 or 2
methods.

 3) What exactly is the practice as far as code
commenting/documentation. The current patch is bare (my local copy has
a smattering of TODO's FIXME's and general blurbs anywhere things get
messy, new, or complex. Most of the other libs don't seem to have the
inline documentation, just some general comments. There are some
smatterings about it in the wiki, but most of the code in SVN isn't
like that, so I just thought I would ask.


Cheers,
Kevin Kubasik


On 9/20/07, Miguel de Icaza <miguel at novell.com> wrote:
> Hello,
>
> > Wow, my complete apologies, I didn't realize the patch was so
> > inflated, its probably mostly line endings, I'll try and slim it down,
> > although if anyone has had some prior experience with a good
> > tool/practice, I'm all ears.
>
> It is best to submit small patches as you go that trying to land a huge
> contribution all at once.
>
> Also, it seems that the 2.2 meg file contained a lot of auto-generated
> code.    It might make sense to write our own tool that generates those
> files instead of checking-in 2.2 megs of generated stuff.
>
> Miguel
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compiledquery_changeset.patch
Type: application/octet-stream
Size: 8999 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070921/0307c906/attachment.obj