[Mono-dev] Linq to Sql Start

Thu Sep 20 12:46:39 EDT 2007

Hey, my last e-mail got bounced for size, so if you really want the
zip, or the patch, everything is at
http://kubasik.net/files/olive_patches/

sorry!

On 9/20/07, Kevin Kubasik <kevin at kubasik.net> wrote:
> Ok, well in addition to the git way:
> git clone http://kubasik.net/git/olive-kkubasik.git
> git branch --track localbranch origin/linq_kubasik
> git checkout localbranch
>
> or the web interface[1], I have included a plethora of patches. The
> first one (kkubasik-olive....) is a simple diff of my working
> directory against subversion head (or almost, theres the anon delay
> and my lazness, but it should be pretty close). The zip is a patchset
> (the way git wants to do them) with a separate patch for every commit
> I've made to my local repo, probably a pain to actually apply, but
> good if your confused over an odd diff. And lastly the RevLog (or as
> its better known git log --pretty --numstat --summary) I'm working on
> a complete(ish) changelog entry, but its pretty big. (I've been
> nabbing some low-hanging fruit as I go, null checking, API updates
> etc.)
>
> Anyways, the patches will probably be (somewhat) obsolete later this
> evening, as I've just been making headway. That doesn't mean ignore
> them, I need some review of whats going on (things like the
> DummyDataProvider.cs DiffWrapper.cs and DiffTracker.cs specifically)
> also any other codeing habits or the like. I've never worked on
> Classlibs before, and I'm completely open to criticizm, please don't
> be afraid of hurting my feeling, most of this code is experimental, to
> see if I've got everything figured out.
>
> On a separate note, if anyone is checking the web interface, or the
> patches, they might notice the TestSuite is currently lots of
> VisualStudio specific autogenerated code, and a Sql Server 2005
> Express Edition database. Being as that toolchain is the only known
> working implementation (there have been several attempts at MySql
> backends, I have head mixed things, some were just decompilations of
> the Sql Provider components with a few syntax changes, and some where
> from scratch and still buggy.) If there's a frontrunner I'll gladly
> port the tests, however, until then, (especially seeing as we don't
> build or run this library by default atm) I would prefer to shelf the
> overhead associated with making those test's crossplatform. Once we
> have some form of implementation (even something like 20-30%
> functional API compatibility, I can get it integrated with makefiles,
> and using dummy objects for our db backend.
>
> All that said, what is the policy for moving this type of code into
> the repo? Would we just keep the test module separate (maybe as an
> svn:external ?) or something, or is it ok?
>
> Anyways, I hope I'm on the right track here, and actually poised to
> help, and not just be a constant question sinkhole. I know that a lot
> of the full-time mono developers telecommute, is there a good time to
> catch people on the IRC or a Jabber conference room?
>
> Anyways, if anyone gets a chance, let me know what possible potential
> solutions might be with regards to the test suite. Please feel free to
> examine/peruse/molest the other code as well, however most of that is
> placeholders etc. until I can flesh out more helper classes/methods.
>
> Here is the ChangeLog entry I wrote for this lump of patches, even
> though its not really a release or anything.
>
> 2007-09-20 Kevin Kubasik <kevin at kubasik.net>
>         * A series of small API Compatability fixes for Beta 2
>         * A Test Project LinqDataTest (Windows Specifict ATM)
>         * The beginnings of a Linq to Sql Test Suite
>         * DataShape.cs -> DataLoadOptions.cs (API Change)
>         * DataContext.cs -> Added missing interfaces and method stubs
>                 * Write and test GetTable()
>                 * Started work on Translate()
>                 * Added missing public Properties
>         * DummyDataService.cs
>                 * Primarily to extend IDataService.cs for testing
>                 * Could potentially become a 'core' implementation
>         * IDataService.cs
>                 * Uncommened interface
>                 * Organized methods by instance-public and everything else
>         * State.cs
>                 * Added a 'ChangeState' enum, as seen in several places on MSDN
>         * Table_T.cs
>                 * Added several missing interfaces
>                 * Method stubs for corresponding methods
>                 * Started work on Add
>                 * Implemented Expression handling
>         * DiffTracker.cs & DiffWrapper.cs
>                 * The backend of Table, will provide access as an IEnumerable
>                 * Allows the sane implementation of SubmitChanges()
>         * ChangeSet.cs
>                 * Working implementation matching docs on MSDN
>         * EntityRef.cs
>                 * BuildFixes when working with Windows
>         * Link_T.cs
>                 * Ported existing elements of implementation to updated API
>         * IExecuteResults.cs & IFunctionResults
>                 * Were mistakenly duplicated originaly, now only one copy of each
>                         lives, in System.Data.Linq
>         * CompiledQuery.cs
>                 * A near-complete implementation - Needs much more testing.
>         * DataQueryProvider.cs
>                 * A skeleton implementation of IQueryProvider, need for the intelligent
>                         handling of DB types
>         * Binary.cs
>                 * Implemented some overrides Equals, ToArray and ToString
>         * In addition, I modified several other files when trying to get the
> net_3_5 profile
>
>
> Cheers!
> Kevin Kubasik
>
>
>
> On 9/20/07, Marek Safar <marek.safar at seznam.cz> wrote:
> > Hi Kevin,
> > > Hey! I've started to get going on some of the System.Data.Linq work,
> > > at the moment, there's not much in terms of real code to show, but
> > > some initial unit tests (my first ever, sorry they're so incomplete)
> > > and API updates (Get the public API more in sync with the current 3.5
> > > Beta 2) and realistic implementation for some of the extension
> > > methods, static methods, and helper style classes. I hope to delve
> > > into Table and DataContext later this week (the real toughies) but
> > > once I 'got' the whole deferred execution thing, this whole system
> > > started to make a lot more sense. (Hence my writing the CompiledQuery
> > > class ;) ).
> > >
> > I am happy to hear that you have made good progress.
> > > Anyways, there's too much file movement to do a sane patch, and since
> > > some of the new files aren't properly integrated into the build
> > > system, I don't want to submit a patch, however, as I clean up the
> > > code and make more progress, I'll release a branch later today, once I
> > > finish cloning SVN for a local repo.
> > >
> > Is it really necessary to clone our SVN?
> > > Anyways, I figured I should drop in some sort of status update, at the
> > > moment, the biggest hurdle for me is getting build systems to play
> > > nice, conceptually, it seems easy enough, just add a makefile event
> > > which outputs the VS projects and solutions. The other thing is I'm
> > > currently using Resharper to run the Nunit tests, and that needs to be
> > > added to the makefiles.
> > >
> > This should not be hard, MWF guys have some script if you want to
> > automate (.sources -> .csproj) conversion.
> > > Before I get in too deep, whats the policy with ChangeLogs? I'm
> > > assuming some sort of comment/description of changes is required,
> > > however, everyone has their specifics, and I didn't see anything in
> > > the wiki. Moreover, should I be submitting individual patches for each
> > > increment I complete? (for example when I finish integrating my tests
> > > into the build, should I submit that patch or wait until my work is
> > > 'done'. Seeing as the namespace I'm working on isn't really at risk of
> > > 'breaking' I would guess that reasonable benchmarks are ok, I'm open
> > > to whatever. Once I have a public branch of my work up, I'll just
> > > reference that.
> > >
> > The preferred way is to submit more small patches split by something
> > common which
> > you can describe in ChangeLog. There is not much activity in olive now, but
> > maintaining your changes in the local repository for long time is not
> > good. Anyone can
> > commit changes which you have already made.
> >
> > Thanks
> > Marek
> >
> >
>
> [1] - http://kubasik.net/git/gitweb.cgi?p=olive-kkubasik.git;a=shortlog;h=linq_kubasik
> --
> Cheers,
> Kevin Kubasik
> http://kubasik.net/blog
>
>

-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: RevLog.txt
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070920/117f823b/attachment.txt 