Table bloat in Linq-SQL

[Andrus]

var db = new MyDb(connString );

causes creation of all objects corresponding to all tables in database.

Database contains 500 tables.
Application accesses only few tables at a time.

Creating large number of objects which are not used is bad design.

How to force Linq-SQL to create table objects only when they are first
accessed ?

Andrus.

[Andrus]

Re: Table bloat in Linq-SQL

I think this is done to be able to create queries at runtime properly

from the expression trees. (otherwise the context will run into unknown
table references).

pgsqlmetal generates code:

public readonly MTable<Customer Customers;

public MyDb(string connStr): base(connStr) {

Customers = new MTable<Customer >(this);
.....

}

Is it reasonable to replace Customer field to delayed instantion property
like

public readonly MTable<Customer customers;

public readonly MTable<Customer Customers {
get { if ( customers=null )
customers = new MTable<Customer >(this);
return customers;
}

Why would you want to create these wrappers at runtime? Because that
way you can't program against them.

My application should run in a lot of customer sites.
Customers may have added additional columns to tables in database.
I need to edit those columns in grid.
So I need to retrieve those properties from database also.

Andrus.

[Andrus]

Re: Table bloat in Linq-SQL

Jon,

I think he means the Table<T- on the RDBMS there wouldn't be
anything triggering assemblies being loaded etc (typically, anyway).
But yes, some more clarity would be nice :)

I'm sorry I was not clear.

Table<Tobject instantion causes assembly containing type T to be loaded.

So my issue is: is it possible and reasonable to change sqlmetal generated
code
so that it does not create tables in Data Context constructor?

Is it possible and reasonable to move table creation to table property
getter by implementing getter like

public readonly MTable<Customer Customers {
get { if ( customers=null )
customers = new MTable<Customer >(this);
return customers;
}

Will Linq-SQL work well in this case in design and run times ?

Or will only reference to Table<Tin assembly cause assembly containing
type T to be loaded ?

If so I think I will create whole extended properties assembly at runtime
and load it fully. If this causes perfomace decrease I hope I can cache this
extented assembly in isolated storage.

I havent seen any .NET application with uses background assembly loading at
startup like windows logon.

Andrus.

[Jon Skeet [C# MVP]]

Re: Table bloat in Linq-SQL

Andrus <kobruleht2@hot .eewrote:

I think he means the Table<T- on the RDBMS there wouldn't be
anything triggering assemblies being loaded etc (typically, anyway).
But yes, some more clarity would be nice :)

>
I'm sorry I was not clear.
>
Table<Tobject instantion causes assembly containing type T to be loaded.

Right, I can understand that.

So my issue is: is it possible and reasonable to change sqlmetal generated
code so that it does not create tables in Data Context constructor?

It may be possible, but it sounds like a bad idea to me. When you
deviate a long way from standard practice, you tend to run into all
sorts of difficulties and very few people are able to help you out.
That's a general observation, not one about LINQ to SQL in particular.

Is it possible and reasonable to move table creation to table property
getter by implementing getter like
>
public readonly MTable<Customer Customers {
get { if ( customers=null )
customers = new MTable<Customer >(this);
return customers;
}

At that point you'd need to know the real details of when the CLR loads
any particular type. It's not something I've ever investigated in
*great* detail, but relying on particular behaviour seems like a bad
idea to me - not because it won't work, but because it'll be very
difficult to maintain.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Marc Gravell]

Re: Table bloat in Linq-SQL

Here is an example of how you can add properties to an object

at runtime.

Thanks, but we've already had that conversation - see Andrus's note
above:

Unfortunatley LinQ-SQL does not support TypeDescriptor define properties.

Marc

[Andrus]

Re: Table bloat in Linq-SQL

Here is an example of how you can add properties to an object at
runtime.
>
http://www.spikesolutions.net/ViewSo...2-ac5448180a65

Thankyou.

Googling for Custom Property Framework returns no exact matches.

Where to find demo and/or trial versions of this framework ?
Where to find more information about the technology used ?

Andrus.

[Andrus]

Re: Table bloat in Linq-SQL

>Unfortunatle y LinQ-SQL does not support TypeDescriptor define properties.

Marc,

why do you think it uses TypeDescriptor ?
Maybe it uses dynamic compiling or even direct IL code emit to create
wrapper class ?

In this case it may support LinQ.

Andrus.

[Marc Gravell]

Re: Table bloat in Linq-SQL

why do you think it uses TypeDescriptor ?

By reading the description. The only real way to add extra properties
(in the normal sense) at runtime is via TypeDescriptor. I know you
have this hybrid app-startup-time/compile-time thing going on, but
that isn't really runtime in the normal sense. Of course, since this
ships with custom UI it is possible that it *doesn't even* go via
TypeDescriptor, but just uses something like an "object this[string
name]" indexer and a lot of UI work...

You're welcome to pay $20 to get the code, but my *suspicion* is that
you'll be mildly disappointed. Up to you.

Marc