Re: Gee vala libgda LINQ

[Juarez Rudsatz <juarezr gmail com>]

Yes, I feel there is nothing new in Linq. They assemble the functional parts of other languages, like Haskell, Python, and others, with the inline SQL syntax that exists in Cobol, ABAP, and other older languages.

However the result of the mix is very practical and usefull for data heavy apps like database, webservices, json/jsonp services.

I feel also that the infrastruture needed is already in a good shape. The libgda and libgee seems to have almost all features required done as pointed by you and Daniel.

We were talking about the missing language features that should contribute do implementing Linq like functionality and should also improve the language itself but no abuse language desing.

I don't know what changes are desired or acceptable for vala desing.

I'm just wondering if the change would be well accepted from vala hackers.

2013/12/8 Maciej Piechotka <uzytkownik2 gmail com>

Sorry for late response - I've had long week and I'm still catching up
with email backlog.

The core features should be in Gee already - it's just called
Traversable instead of Selectable. The 'select' part is just named a
'map' (naming in general is Haskell-inspired then SQL/LINQ-inspired).

Yes, Luca also pointed to this.

For doing this map I think that vala need some new language features:

1. Object initialization ( already in vala )

2. Anonymous objects ( only in C#/.net )

3. Type aliasing ( only in C# )

For understanding this consider the following example in Linq/C# that gets some fields in some records from some database tabel and put in a list with a anonymous type declared in local scope:

 

var query = from myalias in dbcontext.mytable

            where myalias.id == 15
            select new {

                myalias.id,

                newmembername = myalias.name,

                somevalue = myalias.value

            };

This free the developer of declaring a type for local use.
C# creates a anonymous type (a class declaration without name) infering the property types from the types from properties given in the select new.

Mytable is just a plain object class in C# code and DBContext is the Linq implementation:

public class MyTable
{

    int id { get; set; }

    string name { get; set; }

    double value { get; set; }
};

public class dbcontext: DataContext
{

    public DBSet<MyTable> mytable { get; set; }

};

It would not be so useful from libgee perspective but might be much more
from libgda one is ability of operating on AST syntax (I believe LINQ
have this ability but last time I've done anything in C# was ~9 years so
I may be wrong). Otherwise:

C# has the ability to inspect the AST using ExpressionTrees. At compile time they evaluate like common _expression_, except they don't optimize, but at runtime the execution builds a AST tree instead of evaluating the _expression_.

In the example above, the 'query' variable will get a 'IQueryable' type that contains the _expression_ tree.

For get the results of the _expression_ you should invoke the evaluation of the AST tree from Linq simply by using the objetct like:

var newlist = query.ToList();

or

foreach(var item in query)
{

   print("%d - %s - %f", item.id, item.newmembername, item.somevalue);

}

 

So, with this way the developer use the compiler type inference to assist him. In this case the compiler check the names and types of the class and properties.

In a normal database application with hundreds of tables/classes and thousands of queries this is a real performance boost because the compiler catch the erros at compile time cutting the time of testing the erros at runtime.

    select name from gdacollection where id = '123

Personally I think the Linq syntax is to obstrusive.

In the same example above, we can rewrite the syntax so it would be much more consistent with vala design. For example:

var query = dbcontext.from(myalias => Mytable)

           .where(myalias.id = 123)

           .select({

                myalias.id,

                newmembername = myalias.name,

                somevalue = myalias.value

            });

 

would be suboptimal (query by primary key is something any database
should do before breakfast but from straightforward proposition it would
copy all the data into local memory and traverse it).

Yes, this is not acceptable at all.
For this AST handling and result serialization comes handy and conveniently.

I hope this could help to undertand what are the benefits of these features.

Please, let us know your opinion. This looks interesting?

What is needed? What is the effort?

 

On Tue, 2013-12-03 at 20:07 -0600, Daniel Espinosa wrote:
>
>
>
> 2013/12/3 Juarez Rudsatz <juarezr gmail com>
>         I checked the samples and some parts of the code.
>         Nice work. :-)
>
>         Regarding language support, it seems to remain a good amount
>         of work to be done yet.
>
>
> Do you mean Vala features right?
>
>         I'm counting the language features that will be necessary:
>         - Object serialization
>
>
> Are you mean write some where. For XML serialization we have Vala's
> GXml project[1]. On GXml's serialization branch, you'll find my work
> on GObject serialization to XML, comparable with .NET but, I think
> more flexible[2].
>
>         - Anonymous types
>
>         - _expression_ and type introspection
>         - Type aliasing...
>         - Syntax changes
>
>
> At the end a Collection have objects with a set of properties, a
> SELECT _expression_ is a filter of that set of objects and a set of
> properties. They could be stored in a DbRecord (as for libgda's
> GdaData [3] ) to save memory and adding something like
> "Methods_With_Syntax_Support" [4] , Vala compiler could transform:
>
>
>      var selection = select name, salary from employees where id =
> "123";
>
>      stdout.printf (@"$(selection.name) / $(selection.salary)");
>
>
>
> to:
>
>        var _tmp_ = new ArrayList<Employee> ();
>        _tmp_.add_all ( ((Traversable) employees).filter(
>                               (g)=>{ return id.equals (g) true :
> false; });
>
>        var selection = ((Selectable) _tmp_).get_fields ("name",
> "salary");
>
>        if (selection.size != 1)
>
>           throw new SelectableError.MULTIPLE_VALUES_TO_SINGLE ("...");
>
>        var _tmp2_ = selection[0].get_field("name");
>
>        var _tmp3_ = selection[0].get_field("salary");
>        stdout.printf (@"$(_tmp2_) / $(_tmp3_)");
>
>         What level of support you are planning?
>
>
> Because I haven't used LINQ before, I don't know most of its features.
> Just think about to allow:
>
>
> a) Use a SQL like syntax to filter objects and properties, by adding
> support to Vala compiler to generate corresponding Vala or C code
>
> b) Object collection must implement at least Gee.Collection and its
> items must be Gee.Comparable and Selectable
>
> c) Add a Selectable interface to Gee to allow introspect objects
> properties and create a Collection with desired DbRecord set of
> values.
>
>
>
> I don't think mimic LINQ is correct. May we can do better, but is
> necessary to define use cases.
>
>
> The only one I have in mind is:
>
>
> a) select {list-of-fields} from {collection-object} where {condition}
>
>
> For this simple _expression_ Vala's compiler should generate required
> code to:
>
>
> a) Check for collection-object is a GObject implementing
> Gee.Collection and its elements must be Gee.Comparable and Selectable
> b) Check for list-of-fields are public properties in collection-object
>
> c) Check for condition is using collection-object 's public properties
>
> d) Generate a Predicate<G> delegate function to find object required
> objects
>
> e) Fill a Gee.Collection with filtered objects
>
> f) Generate a Gee.Collection from Selectable, that produce rows and
> values/columns (with name=properties' name)
>
>         It would be well received by upstream developers?
>
> Really don't know. I'm CC to Vala and Gee lists to hear them about
> this idea.
>
>         I'm planning a new architecture for ouro next applications and
>         considering vala. But the type safety and language support are
>         the strengths of linq we really appreciate.
>
>         I'm planning to help someway, but I have a long way yet to be
>         produtive.
>
>         Regards
>
>         Juarez
>
>
> [1] https://git.gnome.org/browse/gxml
> [2] https://git.gnome.org/browse/gxml/log/?h=serialization
>
> [3] https://git.gnome.org/browse/libgda/tree/libgda/data
>
> [4]
> https://wiki.gnome.org/Projects/Vala/Tutorial#Methods_With_Syntax_Support
>
>
>         Em 03/12/2013 16:35, "Daniel Espinosa" <esodan gmail com>
>         escreveu:
>
>                 You can see a preview of my work on current stable
>                 libgda.
>
>                 I've finished interfaces and implementations under
>                 GdaData name space.
>
>                 I've added some documentation just use
>                 --enable-vala-extensions --gtk-doc (some other
>                 switches are required) to see it installed.
>
>                 Missed Selectable interface or implementation.
>
>                 I would like to add syntax support on Vala compiler in
>                 order to have LINQ like one.
>
>                 For now is very easy to access to data using GdaData
>                 objects, see unit tests for more examples.
>
>                 El dic 3, 2013 10:03 a.m., "Juarez Rudsatz"
>                 <juarezr gmail com> escribió:
>                         Hi,
>
>
>                         I found that you have been working in a
>                         possible implementation of LINQ in vala [1].
>
>                         I see that you have made good progress
>                         regarding this support.
>                         I want to know what is the current status.
>
>                         What's missing yet? How is the work for
>                         getting basic support ?
>
>
>                         Regards
>
>                         Juarez
>
>
>                         [1]
>                         https://mail.gnome.org/archives/vala-list/2011-December/msg00140.html
>
>
>
>
> --
> Trabajar, la mejor arma para tu superación
> "de grano en grano, se hace la arena" (R) (en trámite, pero para los
> cuates: LIBRE)
> _______________________________________________
> libgee-list mailing list
> libgee-list gnome org
> https://mail.gnome.org/mailman/listinfo/libgee-list