Query.Store() with not temporary table?
0

I would like to be able to import external data (for instance from an excel file) to use it in a LINQ query with DO persistent objects. The tables would be known only at runtime (but not the column that would be known at compile time).

I could do exactly that with Query.Store<T>() (by the ways this is fantastic feature).

But I fear this would have an impact on performance if the row to import are numerous (likely number is around 1000 - 5000, with 2-10 columns). A way to improve this would be to use a normal (not temporary) table. Is it possible to have a mechanism similar to Query.Store<T> to create/refresh it at run time?

asked Sep 02 '10 at 03:40

olorin's gravatar image

olorin
358●87●87●92

edited Sep 08 '10 at 06:16

Alex%20Yakunin's gravatar image

Alex Yakunin
2971●4●4●12
One Answer:
oldest newest most voted
1

I think the best way to achieve this goal is to use a special database and Domain for this, as well as special UdtDomainManager type responsible for its rebuilding:

  • Domain UdtDomainManager.Domain property returns domain for the current configuration (rebuilding it, when necessary).
  • Type UdtDomainManager.AddType(UserDefinedType userDefinedType) registers a new UDT there, returning actual runtime type for it (e.g. generated by CodeDOM),
  • UdtDomainManager.RemoveType(UserDefinedType userDefinedType) removes previously registered UDT.

Having such manager, it's pretty easy to deal with custom types.

If it's necessary to maintain everything in a single database, such type must be used as your only domain provider.

answered Sep 02 '10 at 10:53

Alex%20Yakunin's gravatar image

Alex Yakunin
2971●4●4●12

edited Sep 02 '10 at 10:54

Please get me right: Query.Store<T> is designed to work well in their own specific cases. E.g. we have even RSE provider handling it. It is designed to act only as it's intended. Trying to use it in your case isn't a good idea.

(Sep 02 '10 at 13:50) Alex Yakunin Alex%20Yakunin's gravatar image
1

On the other hand, we'd be willing to write a sample for the case I just described, if you're interested.

(Sep 02 '10 at 13:52) Alex Yakunin Alex%20Yakunin's gravatar image

You're right this is not a good idea to use Query.store<t> for this scenario.

A naive question : is it possible to use objects from several domains in a single linq Query? This is the final expected behavior.

(Sep 07 '10 at 02:46) olorin olorin's gravatar image

I'm certainly interested by a sample ;)

(Sep 09 '10 at 04:51) olorin olorin's gravatar image

> is it possible to use objects from several domains in a single linq Query?

No, this isn't possible. AFAIK, there are no ORM tools that support this case.

(Sep 09 '10 at 09:59) Alex Yakunin Alex%20Yakunin's gravatar image

Concerning the sample: I created issue 805 and assigned it to v4.4.

(Sep 09 '10 at 10:04) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

about | faq | privacy | support | contact us

powered by OSQA