Hi,

Congratulations on shipping V4

You say that you can now use QuerySpec with TypedLists, does that mean they serialize okay over WCF instead of having to send them as Datatables?

Does the performance increase in Entity fetches relate to overall performance (including QuerySpec and Linq providers) or just the native API? (QuerySpec was already fast).

Any feedback as always is appreciated.

Thanks, Norman.

NMackay wrote:

Hi, Congratulations on shipping V4

Thanks!

You say that you can now use QuerySpec with TypedLists, does that mean they serialize okay over WCF instead of having to send them as Datatables?

They're datatables (they derive from datatables, like typed datatables do too in vs.net), so serializing them will use the xml serialization inside the datatable class. To me it should be the case that you can serialize a typed list in v3 code as well and deserialize it as a typedlist on the other side. The fetch logic is solely for query generation.

Does the performance increase in Entity fetches relate to overall performance (including QuerySpec and Linq providers) or just the native API? (QuerySpec was already fast).

The performance gains are in the entity materialization so the conversion from datareader row to entity class instance. So all query api's benefit from this, as the performance gains are inside the entity objects themselves Linq and queryspec both convert to low-level API calls, so in the end they all end up in methods like FetchEntityCollection.

Hope this helps.

Frans,

Thanks for your feedback

They're datatables (they derive from datatables, like typed datatables do too in vs.net), so serializing them will use the xml serialization inside the datatable class. To me it should be the case that you can serialize a typed list in v3 code as well and deserialize it as a typedlist on the other side. The fetch logic is solely for query generation.

Hi Frans,

Yeah, I'm aware it's the way it's working but I can serialise IEntityCollection2 and iEntity2 with WCF quite happily, with typed lists I have to do:

// Interface

<OperationContract()> _
Function GetOrderHistory(ByVal OrderID As Int32) As DataTable


 // Service implementation
 Public Function GetOrderHistory(ByVal OrderID As Int32) As DataTable

            Dim Adapter As New DataAccessAdapter

            Try

                Dim QF As New QueryFactory
                // Do the queryspec queery

                Dim results As DataTable = Adapter.FetchAsDataTable(Query)
                results.TableName = "OrderHistoryByID"  '// WCF needs a table name for serialization

                Return results


// Client side
If WCFService IsNot Nothing Then
Dim OrderHistory = WCFService.GetOrderHistory(10001)

    If OrderHistory IsNot Nothing Then
        datagrid_results.DataSource = OrderHistory 

Idealy I'd like to make my TypedList a known service type in the interface and have the function return ITypedList2, it just makes things a little tighter. It's not the end of the world if this isn't possible, I just always felt this was a workaround since the other type's serialized okay.

We're reviewing or WCF strategy for our next big development so just wanted to clear this one up.

Just to be clear we can only pass TypedView's as DataTables?

Thanks, Norman.

TypedList inherits from DataTable as well as the interface ITypedList, I don't see a reason why do you want to define a new "known type" while you can use DataTable in the service method declaration.

What's the difference this could make?

Walaa wrote:

TypedList inherits from DataTable as well as the interface ITypedList, I don't see a reason why do you want to define a new "known type" while you can use DataTable in the service method declaration.

What's the difference this could make?

I disagree but I guess it's a no so it doesn't matter.

NMackay wrote:

Yeah, I'm aware it's the way it's working but I can serialise IEntityCollection2 and iEntity2 with WCF quite happily, with typed lists I have to do:

// Interface

<OperationContract()> _
Function GetOrderHistory(ByVal OrderID As Int32) As DataTable


 // Service implementation
 Public Function GetOrderHistory(ByVal OrderID As Int32) As DataTable

            Dim Adapter As New DataAccessAdapter

            Try

                Dim QF As New QueryFactory
                // Do the queryspec queery

                Dim results As DataTable = Adapter.FetchAsDataTable(Query)
                results.TableName = "OrderHistoryByID"  '// WCF needs a table name for serialization

                Return results


// Client side
If WCFService IsNot Nothing Then
Dim OrderHistory = WCFService.GetOrderHistory(10001)

    If OrderHistory IsNot Nothing Then
        datagrid_results.DataSource = OrderHistory 

Idealy I'd like to make my TypedList a known service type in the interface and have the function return ITypedList2, it just makes things a little tighter. It's not the end of the world if this isn't possible, I just always felt this was a workaround since the other type's serialized okay.

Though why not define the typedlists as well known types as well?

We're reviewing or WCF strategy for our next big development so just wanted to clear this one up.

Just to be clear we can only pass TypedView's as DataTables?

Could you elaborate a bit about what you mean exactly? TypedViews and TypedLists are for serialization purposes more or less equal as both derive from datatables. You can pass typedviews as typed classes but not typedlists?

Sorry,

Just noticed an error.

I meant TypedView. You cannot serialize TypedView2 over WCF using LLBLGEn 3.1/3.5, you have to pass it as datatable.

Sorry about the confusion, had that Novo virus (think food poisoning x10) and my 1st day back wasn't thinking clearly.

It's not the end of the world if you have to pass as datatables, I was just wondering if this was possible in 4.0.

As it is

 <OperationContract()> _
        Function GetOrderHistory(ByVal OrderID As Int32) As DataTable

Rather have:

 <ServiceKnownType(GetType(VOrderHistoryByID))> _   '// -- this causes a serialization error

 <OperationContract()> _
        Function GetOrderHistory(ByVal OrderID As Int32) As ITypedView2
        // QuerySepc query returning VOrderHistoryByID

Sorry for the confusion,

No food for three days doesn't focus the mind, apologies to Walaa for my shortness.

As far as I remember you can serialize TypedViews from a WCF service in v3.x as follows: Using the WCF example posted on our website, I added the folowing code, and it works perfectly.

NorthwindService.cs (the WCF interface)

    [ServiceKnownType(typeof(InvoicesTypedView))]
    public interface INorthwindService
    {
        [OperationContract]
        ITypedView2 GetInvoices(); 

CustomerService.cs (The service implementation)

public ITypedView2 GetInvoices()
{
    var invoices = new InvoicesTypedView();

    using (DataAccessAdapter adapter = new DataAccessAdapter())
    {               
        adapter.FetchTypedView(invoices, null, 5, false);
    }

    return invoices;
} 

The client code:

InvoicesTypedView invoices = (InvoicesTypedView) DalService.GetInvoices(); 

When you host the WCF service on IIS, and access it from the client application, it works perfectly. The issue is that you are trying to access the service from the Browser. And this won't work, as the Browser.. (i.e. the WSDL) have no idea about the special types you use in the service.

Now you would ask why the service shows no error when we remove the method which returns a TypedView, although we have methods returning entityCollection and entities.

My guess would be the WSDL don't try to serialize/deserialize objects it doesn't know, so it won't fail trying to work with Entities and EntityCollection. But in the case of a TypedView, it sees it as a DataTable (since TypedView inherits from DataTable), but when it tries access the rows and the columns it fails. That's why we might want to return a dataTable, instead of the TypedView type.

No food for three days doesn't focus the mind, apologies to Walaa for my shortness.

No problem at all, sorry to hear about your illness, hope you are much better now.

Walaa wrote:

As far as I remember you can serialize TypedViews from a WCF service in v3.x as follows: Using the WCF example posted on our website, I added the folowing code, and it works perfectly.

NorthwindService.cs (the WCF interface)

    [ServiceKnownType(typeof(InvoicesTypedView))]
    public interface INorthwindService
    {
        [OperationContract]
        ITypedView2 GetInvoices(); 

CustomerService.cs (The service implementation)

public ITypedView2 GetInvoices()
{
    var invoices = new InvoicesTypedView();

    using (DataAccessAdapter adapter = new DataAccessAdapter())
    {               
        adapter.FetchTypedView(invoices, null, 5, false);
    }

    return invoices;
} 

The client code:

InvoicesTypedView invoices = (InvoicesTypedView) DalService.GetInvoices(); 

When you host the WCF service on IIS, and access it from the client application, it works perfectly. The issue is that you are trying to access the service from the Browser. And this won't work, as the Browser.. (i.e. the WSDL) have no idea about the special types you use in the service.

Now you would ask why the service shows no error when we remove the method which returns a TypedView, although we have methods returning entityCollection and entities.

My guess would be the WSDL don't try to serialize/deserialize objects it doesn't know, so it won't fail trying to work with Entities and EntityCollection. But in the case of a TypedView, it sees it as a DataTable (since TypedView inherits from DataTable), but when it tries access the rows and the columns it fails. That's why we might want to return a dataTable, instead of the TypedView type.

No food for three days doesn't focus the mind, apologies to Walaa for my shortness.

No problem at all, sorry to hear about your illness, hope you are much better now.

Thanks for your assistance, I'll try it again.