2009/6/17 Andrus Moor
>
> > Step 1 is lines 3-4, taking 348820 ticks.
>
> Unlike others, step 1 is speed probably exponentially depends from the
> number of tables in DataContext class:
>
> If DataContext contains 2 times more tables, number of relations (class
> members) will typically increase
On Wed, Jun 17, 2009 at 2:01 AM, greyman wrote:
>
> It's arguable the
> identity management and query caching in DbLinq won't be of much
> benefit if the DataContext is only used for single units of work.
>
This is related to how you define a Unit of Work.
You should not need identity map out o
When I went to similar issue, I've opted for extesion (see
DataContext.GetIDbCommand()).
We could add some DataContext method to enable the building of such
parametric queries allowing the user to use them as he like.
That said, we (at my company) really need DbLinq as a Linq to Sql
replacement/i
ReadTests_Math.Log01() Fail with an exception, and it's not [Explicit] on
SqlServer
And the worse is that it's producing sql semantically different from the
linq query.
SELECT COUNT(*)
FROM [dbo].[Order Details]
WHERE ((LOG(([Discount] + 1))/LOG(2,71828182845905)) > 0)
while the linq was
I guess this is a bug hiding other bugs...
Giacomo
2009/6/16 Federico Di Gregorio
> PostgreSQL fails the
>
> DbLinq.PostgreSql_test.Test_NUnit_PostgreSql.AnyCount.FirstInternal03
>
> with an exception about an unknown expression type:
>
> System.ArgumentException: Parameter
>
> and in fact in
09 at 2:18 PM, Giacomo Tesio wrote:
> If you'd really to become a DbLinq contributor by fixing the QueryCache
> issue you should write an ExpressionChain visitor which is able to traverse
> ExpressionChain as ExpressionDispatcher.Analyze() does.
>
> This should not be that compl
k, time,
> and skill needed.
> Where can I go for more details?
>
> On 5 jun, 10:46, Giacomo Tesio wrote:
> > If disabling QueryCache by default is fixing that bug than yes, it's
> fixed.
> >
> > As a result of that discussion I've introduced the possibil
-08 at 13:21 +0200, Giacomo Tesio wrote:
>
> http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
>
> Nice!
>
> And here I thought that Linq to SQL was effectively dead...
>
> BTW, it quite clear that ITable would probably require some (deep?)
> refactoring
Many tell that l2sql will be unsupported but read this:
http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
What do you think about?
BTW, it quite clear that ITable would probably require some (deep?)
refactoring for us...
Giacomo
--~--~-~--~~~---~--~
th entry in the DbLinq todolist...
BUT with QueryCacheEnabled == false, that issue should disappear.
Giacomo
On Sun, Jun 7, 2009 at 3:22 PM, wrote:
>
>
>
> On Jun 5, 7:29 am, Giacomo Tesio wrote:
>
> > > A difficulty I have had with DbLinq is the fact that it also acts
If disabling QueryCache by default is fixing that bug than yes, it's fixed.
As a result of that discussion I've introduced the possibility to disable
the QueryCache which is still broken.
Later I've made it disabled by default.
Jon would like to completely remove it, while I still have some idea
The latest svn version have QueryCache disabled by default, but QueryCache
(currently broken) is just a cache of SQL selects, not of results.
Actually I've found no result cache at all.
AFAIK, no query result cache exists, just an ObjectTracker (DataContext
scoped) which allow you to get the same
Another thing: try test running on Sql Server (release configuration).
I fear that we still have different datas (even in Northwind! ! !) since Jon
marked to be skipped also tests that run for me!
Giacomo
On Thu, Jun 4, 2009 at 6:56 PM, Giacomo Tesio wrote:
> Committed.
>
> Now REL
)" in ExpressionDispatcher.Analyzer.cs, uncomment it and make
it work!
I've started this work, but it's quite long and I've no time now...
On Thu, Jun 4, 2009 at 9:24 AM, Giacomo Tesio wrote:
> Please take a look to the attached patch (against r1104).
>
> It enable ALL tests to
I'm not a .NET security expert, but this is probably due to the way
ReflectionObjectFactory works (by reflecting the current assembly).
I do not know if the other parts of DbLinq would works in partial trust
(since it often use some kind of reflection), but IMHO
ReflectionObjectFactory sucks...
Y
> #endif
> {
> }
>
> // and similar for SqliteKnownFailure, etc.
>
>
> This would allow tests such as:
>
> [SqlServerKnownFailure]
> [Test]
> public void FirstInternal02() {...}
>
>
> (The #if within the SqlServerKnownFailureAttribute dec
pass than fail, so use [Category] to
> mark tests that should pass would result in *more* methods being
> attributed than marking those that fail (which is why I suggested marking
> failing tests).
>
> As for tests failing on some vendors but not others, we just need to use
>
MemberInfo) methods, one of which is private and commented out. Would you
> mind removing the commented out version (as it's obviously no longer
> needed)?
>
> Thanks,
> - Jon
>
>
> On Thu, 2009-05-28 at 12:02 +0200, Giacomo Tesio wrote:
>
> Another strang
e.org/optoverview.html#flattening
Giacomo
On Sat, May 30, 2009 at 9:01 PM, Giacomo Tesio wrote:
> I'm not a linq expert user, so I can't write unit tests to generate
> subqueries. At least not so variuos and so smart.
>
> But I'm quite sure we will need those soon.
>
I'm not a linq expert user, so I can't write unit tests to generate
subqueries. At least not so variuos and so smart.
But I'm quite sure we will need those soon.
Can someone improve the number of unit tests in ReadTests_Subquery?
Giacomo
--~--~-~--~~~---~--~~
Yo
ion.
This is so strange that I'm wondering if it was an error or not.
BTW, changing the m to n made more than 5 unit tests to pass.
Giacomo
On Tue, May 26, 2009 at 10:23 PM, Giacomo Tesio wrote:
> I'm to commit (tomorrow) a big patch fixing 21 unit tests.
>
> I've onl
I'm to commit (tomorrow) a big patch fixing 21 unit tests.
I've only tested on SqlServer so I suggest to search for regressions on the
other vendors.
One fix is related to wrong data not reling on the microsoft northwind db:
there's no Pen in the Northwind products' table (at least in the current
Lazy loading finally work, but we should take in account Eager loading.
This would mean to postprocess BuilderContext to add what is needed to the
original query (when, and only when the return type of the query contains
entities for which any loadoption are registered AND the
DataContext.Deferred
I'm wondering about what's needed to implement subqueries which are the next
maior step in the development.
AFAIK, a maior refactoring could be required, since:
- the BuilderContext is not a tree, so subqueries are mixed with the
parents.
- the ExpressionDispatcher analisis is done from the expres
I've just committed a patch to enable the correct (I hope) management of
some DbLinq use cases showed in
ReadTest.C20_SelectEmployee_DbLinqAsQueryObject().
To pass this have required some modification to the SqlProvider base class:
GetLiteralOr and GetLiteralXor now return their result between '('
rs?
>
> I think having machine A throw makes far more sense here, as it's never a
> good idea to silently lose data.
>
> - Jon
>
>
> On Wed, 2009-05-20 at 11:45 +0200, Giacomo Tesio wrote:
>
> Again on this topic: reading more deeply the r1073 changelog I sa
y 20, 2009 at 9:35 AM, Giacomo Tesio wrote:
> Hi, I've noticed a strange behaviour in the
> ReadTest.C16_GettingProperty_DeferredLoadingEnabled2False()
> It pass if run alone, but fail if run in tandem with the others...
>
>
> I've also noticed that it has been m
Please, take a look to this commit, which allow to disable the QueryCache
usage from query done from a certain datacontexts:
http://code.google.com/p/dblinq2007/source/detail?r=1076
Currently this is by default true (enabled) becouse of backward
compatibility.
Frankly, we (at my company) absolut
Hi, I've noticed a strange behaviour in the
ReadTest.C16_GettingProperty_DeferredLoadingEnabled2False()
It pass if run alone, but fail if run in tandem with the others...
I've also noticed that it has been modified the EntityTracker property in
the DataContext class to a more proper name "Current
I think we should leave a logging bot connected...
Giacomo
On Wed, May 13, 2009 at 4:03 PM, Jonathan Pryor wrote:
> I have created a ##dblinq IRC channel at irc.freenode.net, to support
> developers who like to use IRC as a more immediate communication channel
> than the mailing list. (I've b
ressionMutator. And because Expressions are immutable, we
> needed to create new mutated expressions from old ones.
>
>
> On Sun, May 17, 2009 at 21:53, Giacomo Tesio wrote:
>
>> Tring to organize the work needed to make the QueryCache useful by
>> allowing each Inpu
Tring to organize the work needed to make the QueryCache useful by allowing
each InputParameterExpression to update it's own values from the updated
expression, I encountered the ExpressionMutatorFactory and all the
IMutableExpression implementations.
This is something I could not understand yet,
generation
> will be slower than either the expression tree generation or the parsing.
> I'm not sure it's sensible to try to just cache the results of SQL
> generation, though it *may *be sensible to try to cache the results of our
> "optimized" expression typ
I'm still analizing the question.
QueryCache is busted. The only way to make it work is to do what was
> originally done (make values part of the cached values), which results in
> large memory use as every query variation is stored uniquely.
>
If InputParameterExpression would Expression>
conta
this?
Giacomo
On Sat, May 16, 2009 at 8:54 PM, Giacomo Tesio wrote:
> No it probably wasn't...
>
> But with the old approach the query cache hit only with queries with
> identical parameter values. This lead in a performance problem, since memory
> grow too much (a query
)would
>>> "fix" the key lookup over using the expression tree itself, still
>>> isn't an ideal fix: ToString() requires traversing the (possibly quite
>>> large) expression tree, and would thus add additional overhead just to
>>> perform the c
elegate returned by
> CompiledQuery.Compile() to re-create the expression tree, nor to re-parse
> it, which saves time (which is why CompiledQuery exists in the first
> place).
>
> *Please* consider implementing CompiledQuery.
>
> - Jon
>
>
> On Sat, 2009-05-16 at 09
(from p in db.People
>where p.LastName == lastName
> select p)
> .Skip(start)
> .Take(count));
> foreach (p in peopleWithLastName(myDB, "Foo", 0, 1)) ...
>
> Alas, CompiledQuery.Compile() will only create deleg
> tax on the app.)
>
> I would *strongly *suggest that you follow Microsoft's approach, drop the
> DataContext query caching, and use CompiledQuery instead.
>
> - Jon
>
>
> On Fri, 2009-05-15 at 10:25 +0200, Giacomo Tesio wrote:
>
> OFFTOPIC about the interfaces
Microsoft. :-D
Giacomo
On Fri, May 15, 2009 at 10:00 AM, Giacomo Tesio wrote:
> That's a good question, i think.
>
> QueryCache is a cache of generated queries for each expression tree
> evaluated.
> It actually has to be static (at least thread static, but this would
>
nected to
> the DataContext, and thus it could be holding cached data for a
> DataContext that no longer exists. (This may not be the case anyway; I
> haven't fully read and understood the code. I'm just trying to make clear
> that preferring shared caches isn't an open
I've two need:
- Thread Safety of static caches: should be done for QueryCache, but Jon
have encountered a strange (unreproduced on tests) bug while working on
NerdDinner. If no other static cache exists they are ok.
- XmlMappingSource working correctly: now, associations are not loaded from
exter
+1
(just use a different prefix for issues...)
Giacomo
On Wed, May 13, 2009 at 9:15 PM, Leonardo Stern wrote:
>
> On Wed, 2009-05-13 at 18:51 +, Jonathan Pryor wrote:
>> > Would anyone be opposed to having email messages sent to the group
>> > prefixed with [dblinq] (or similar)? I direct
I agree for a different group.
Alternativelly we should allow some tagging for email coming from issue
tracker (a [ISSUE] prefix in the subject or the so).
Giacomo
On Wed, May 13, 2009 at 8:49 PM, Jonathan Pryor wrote:
>
> On Wed, 2009-05-13 at 13:39 -0400, Adam Tauno Williams wrote:
> > Poss
As far as I know from my 0.1 contribution, the biggest problem tring to help
is diving into the code.
As any complex project, DbLinq have a complex architecture which should be
documented a bit more.
(I know I could do it myself...)
Another thing we are really missing is a new "stable" release (a
> within the file, so I'm not sure what mechanism is used to update all
> Products attached to the Category.
>
> Thoughts?
> - Jon
>
> On Mon, 2009-05-11 at 20:22 +0100, Giacomo Tesio wrote:
>
> Than probably its related with the InsertOnSubmit().
>
> Table refer t
gt; directly involved, though, since there isn't any connection between
> EntitySet and DataContext (so there'd be no way afaik for
> EntitySet.Add() to implicitly register values).
>
> - Jon
>
>
> On Mon, 2009-05-11 at 17:26 +0200, Giacomo Tesio wrote:
>
> I kn
/ The above now works. Now...
>
> RSVP rsvp2 = new RSVP();
> rsvp2.AttendeeName = "whatever";
> dinner.RSVPs.Add(rsvp2);
> db.SubmitChanges();
> // rsvp2 is NOT submitted to the database.
>
> I'm still tracking down why this happens. The attached patch file
I've tried some test, and it seemed to be working.
At least, it's not what I was thinking.
Have you finally found a failing test for this use case?
It seem related to web environment. Was it running on IIS?
Giacomo
On Mon, May 11, 2009 at 12:26 AM, Giacomo Tesio wrote:
>
nner.RSVPs.Add(rsvp);
> db.Dinners.InsertOnSubmit(dinner);
> db.SubmitChanges();
>
> // The above now works. Now...
>
> RSVP rsvp2 = new RSVP();
> rsvp2.AttendeeName = "whatever";
> dinner.RSVPs.Add(rsvp2);
> db.SubmitChanges();
> // rsvp2 is NOT submitted to
I think this is due to the "dinner.RSVPs.Add(rsvp);" line where you
actually fill the EntitySet.
The DataContext.SetEntitySetQueries() should not run on just inserted
entity, since they are yet filled.
Tomorrow I'll try to fix this...
Giacomo
On Fri, May 8, 2009 at 4:59 AM, Jonathan Pryor
As far as I remember, some week ago I've "fixed" a bug about the querycache:
in the expression comparer I compare expression.ToString().
If the expression cached contains the parameter value too, this "fix" would
be a bug.
But, the fact itself that the query cache contains parameter's values woul
t; interfaces superior to abstract classes, for our current uses? I'm not
> seeing any use of multiple-inheritance, nor value types, so I don't
> currently see any circumstances that would *require* interfaces.
> Meanwhile, using classes would permit easier sharing
just some:
3: in the medium term, I hope to find time to move dblinq to a better
service location infrastructure.
(actually i'm thinking about the Common Service Locator)
I agree that some interfaces could be removed, but some should not (as
IQueryCache for example). We should only remove thos
como
On Wed, May 6, 2009 at 8:44 AM, Giacomo Tesio wrote:
> [3] write a "simple" software monitoring checkins and running all tests at
> each checkin. When it notes some regression, it would mail all the
> developers a notification.
>
> BTW I've to note that
> 1) So
[3] write a "simple" software monitoring checkins and running all tests at
each checkin. When it notes some regression, it would mail all the
developers a notification.
BTW I've to note that
1) Some test are wrong coded: they do not really test what they should
(noticed on some of the 101 modified
27 PM, Jonathan Pryor wrote:
> On Tue, 2009-04-28 at 14:25 +0200, Giacomo Tesio wrote:
>
> You are surely right, but till now lambda expressions could not modify
> values...
>
> What do you mean by "modify values"? This certainly works:
>
> int n = 1;
> Ac
Where? It would be very useful also for our domain model... :-D
Giacomo
On Tue, Apr 28, 2009 at 4:11 PM, Pascal Craponne wrote:
> Yes, both things are possible, and DbLinq already does such things when
> building entities.
>
>
> On Tue, Apr 28, 2009 at 16:07, Giacomo Tesio
o :)
>
>
> On Tue, Apr 28, 2009 at 14:25, Giacomo Tesio wrote:
>
>> You are surely right, but till now lambda expressions could not modify
>> values...
>>
>> So we could use them for reading keys, for example, but not for setting
>> them...
>> There
is hard to master and impossible to debug, I
> strongly suggest using Lambdas and compiling them. The produced code has a
> good quality, and it's more flexible to maintain.
>
>
> On Tue, Apr 28, 2009 at 09:17, Giacomo Tesio wrote:
>
>> This would be useful too, for Id
This would be useful too, for IdentityKey's creation:
http://rogeralsing.com/2008/02/26/linq-expressions-access-private-fields/
Giacomo
On Tue, Apr 28, 2009 at 9:09 AM, Giacomo Tesio wrote:
> Ah... ! ! !
>
> Thanks Google! :-D
>
> http://geekswithblogs.net/johnsperfblog
, Giacomo Tesio wrote:
> To improve datamapper performances I need to use Emit (and I've to study it
> too... :-D)
>
> But, does Mono support it?
>
>
> Giacomo
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed
On Mon, 2009-04-27 at 21:31 +0100, Giacomo Tesio wrote:
>
> Jon I have a question about Mono license and codeplex code: IObjectFactory
> is really similar to a ServiceLocator, and P&P team released a pluggable one
> on codeplex (http://www.codeplex.com/CommonServiceLocator).
> The
To improve datamapper performances I need to use Emit (and I've to study it
too... :-D)
But, does Mono support it?
Giacomo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send
In a moment of maddness I've tried to improve performances of
ExpressionEqualityComparer.Equals() by comparing Expression.ToString().
>From my tests, querycache retrieving was reduced to a 1%. After some test
I've understood it was a bug, since Equals simply didn't worked for some
expressions (mak
aid... I'll try! :-D
Giacomo
On Mon, Apr 27, 2009 at 8:21 PM, Jonathan Pryor wrote:
> On Mon, 2009-04-27 at 13:03 +0200, Giacomo Tesio wrote:
>
> Should we be able to handle different mappings for the same AppDomain on
> the SAME Type?
>
> Glib answer: write a test and
athan Pryor wrote:
> On Mon, 2009-04-27 at 13:35 +0200, Giacomo Tesio wrote:
>
> Singletons and Implementations dictionaries should be thread safe,
> shouldn't them?
>
> Yes. By default, *instance* members need not be thread-safe, but
> *static*members
> *must* be threa
Singletons and Implementations dictionaries should be thread safe, shouldn't
them?
Moreover since shared, the singletons it provide must be thread safe. They
are.
But... I could try to make them faster using ReaderWriterLockSlim.
Giacomo
--~--~-~--~~~---~--~~
You
Should we be able to handle different mappings for the same AppDomain on the
SAME Type?
It seem to me a quite rare situation in which the same entities are mapped
differently on different DataContext.
I ask becouse I'm plannig a static cache for DataMapper and IdentityReader.
If we should handle
have a thread safe class. So the locks can be
> removed, and maybe if we decide to go thread-safe anyway, we can simply
> place the locks at the DataContext level, not below.
>
>
> On Sat, Apr 25, 2009 at 12:53, Giacomo Tesio wrote:
>
>> Looking at the EntityTraker cla
20 will be better, but not better than 0.21 ;)
>
>
> On Sat, Apr 25, 2009 at 13:18, Giacomo Tesio wrote:
>
>> Write in this thread what you require from the 0.19 stable release:
>>
>> - XmlMappingSource working correctly (high priority, for me)
>> - Thread Safety o
Write in this thread what you require from the 0.19 stable release:
- XmlMappingSource working correctly (high priority, for me)
- Thread Safety of static caches (high priority, for me)
- Lazy Loading (should be quite complete... please take a look at current
code...)
Giacomo
--~--~-~--
How many static caches (and which) there are in DbLinq?
I've made QueryCache thread-safe and I'm planning to create a static cache
for the DataMapper (since, given a mapsource, mapping should not change over
request).
Are there other static caches that I ignore?
Giacomo
--~--~-~--~
Looking at the EntityTraker class I saw two strange things:
- It keep both a List and a Dictionary: why not keep just the dictionary and use its Values property
for EnumerateAll?
- It use locks. Why? It exists in the DataContext which not need to be
threadsafe when ObjectTracking is enabled.
Can I
At home, I'm currently using VS Express...
Giacomo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to dblinq@googlegroups.com
To unsubscribe from this group, send em
Lazy loading should be almost done... I'll submit as soon as possible.
DataMapper and DataContext ignoring XmlMappingSource is still a bug, but I
want to fix one thing at a time...
Also static caches thread safety are in my todo list along with DataMapper
refactoring.
What I want to ask here is t
important, I just mean that thread-safety is
> out of DbLinq scope.
>
>
> On Thu, Apr 23, 2009 at 10:25, Giacomo Tesio wrote:
>
>> @Jon: does Mono support ReaderWriterLockSlim? have you got some objection
>> about creating a set of static thread safe dictionaries for
@Jon: does Mono support ReaderWriterLockSlim? have you got some objection
about creating a set of static thread safe dictionaries for mappings?
@Pascal: is QueryCache thread safe? could it be improved by using the Brian
Rudolph code?
Giacomo
On Wed, Apr 22, 2009 at 4:31 PM, Giacomo Tesio
ehm... I'm blind :-D
Thanks a lot!
Giacomo
On Wed, Apr 22, 2009 at 4:04 PM, Andrus wrote:
>
> http://devplanet.com/blogs/brianr/archive/2008/09/29/thread-safe-dictionary-update.aspx
>
>
> - Original Message -----
> *From:* Giacomo Tesio
> *To:* dblin
Also DataContext.SetEntityRefQueries() and DataContext.SetEntitySetQueries()
has the same problem
Giacomo
On Tue, Apr 21, 2009 at 2:13 PM, Giacomo Tesio wrote:
> DataMapper.GetEntityRefAssociations() and
> DataMapper.GetEntityRefAssociations() depend on Attribute based mapping.
???
where?
On Wed, Apr 22, 2009 at 3:45 PM, Andrus wrote:
> There is also 3 days newer blog entry about this:
>
> //
> http://devplanet.com/blogs/brianr/archive/2008/09/29/thread-safe-dictionary-update.aspx
>
> Andrus.
>
> - Original Message -
> *From:* Gi
any experience
about multi threads on .NET so it should be evaluated)
On Tue, Apr 21, 2009 at 2:13 PM, Giacomo Tesio wrote:
> DataMapper.GetEntityRefAssociations() and
> DataMapper.GetEntityRefAssociations() depend on Attribute based mapping.
>
> So XmlMappingSource could not work
I'm impressed from the ExpressionEqualityComparer efficiency...
Really a good work.
Giacomo
On Tue, Apr 21, 2009 at 9:45 AM, Giacomo Tesio wrote:
> Have you got some unit test for lazy loading?
>
> I'm starting the implementation. It doesn't seem too complex given th
In a SQL transaction such behaviour would be right.
But, this is probably a bug. How Linq to Sql work on such a query?
Giacomo
On Tue, Apr 21, 2009 at 3:07 PM, wrote:
>
> Hi,
>
> The query below works ok in DBlinq-0.18 but in Trunk the datetime in
> the where clause stays the same for each at
DataMapper.GetEntityRefAssociations() and
DataMapper.GetEntityRefAssociations() depend on Attribute based mapping.
So XmlMappingSource could not work correctly on EntityRef and EntitySet
(neither on Mono nor on Microsoft.NET).
Giacomo
--~--~-~--~~~---~--~~
You r
, Apr 21, 2009 at 10:03 AM, Pascal Craponne wrote:
> We should:- move it to an "obsolete" branche
> - release a new package without VisualMetal.
>
> But who is "we"?
>
>
> On Tue, Apr 21, 2009 at 08:58, Giacomo Tesio wrote:
>
>> I think we
Ping... Pascal?
On Sat, Apr 18, 2009 at 10:21 AM, Giacomo Tesio wrote:
> I don't know linq enougth to know how to write one, but yet I know we could
> need it.
>
> Does DbLinq support subqueries?
>
>
> Giacomo
>
--~--~-~--~~~---~--~--
sted, please help me focus and write some good test), I'll
start to create a new wix project for a new release.
Could MSIs work on Mono platforms?
Giacomo
On Mon, Apr 20, 2009 at 11:24 AM, Pascal Craponne wrote:
> Yes, you got the idea.
>
>
> On Mon, Apr 20, 2009 at 10:41, Gi
I think we should remove VisualMetal from the svn, shoudn't we?
Giacomo
On Tue, Apr 21, 2009 at 6:30 AM, Pascal Craponne wrote:
> Use DbMetal instead, VisualMetal is not supported anymore.
> And also, when you have an error, explain a bit more than this.
>
>
> On Tue, Apr 21, 2009 at 04:07, w
ice architecture. Worse, we could get problems when the DataContext
> connection is closed. This is usually why lazy loading isn't allowed from
> outside a service call, because the connection and transactions are closed,
> and lazy loading can not be performed anymore.
>
> There may
I've found them running against Linq to Sql, not using DbLinq.
Could this be related with Mono?
Giacomo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to dblinq@go
I don't know linq enougth to know how to write one, but yet I know we could
need it.
Does DbLinq support subqueries?
Giacomo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, se
Here are 2 little file containing sample code that could be used for unit
testing...
The mapping is for SqlServer.
Hope it help. :-D
Giacomo
On Fri, Apr 17, 2009 at 4:54 PM, Giacomo Tesio wrote:
> Ok, thanks a lot! :-D
>
> I've done, moving XmlMappingSource.cs in DbLinq.Dat
doc
about http://msdn.microsoft.com/en-us/library/bb386907.aspx)
@Jon: please take a look you too: I could have broken something on mono...
Giacomo
On Fri, Apr 17, 2009 at 3:15 PM, Jonathan Pryor wrote:
> On Fri, 2009-04-17 at 11:43 +0200, Giacomo Tesio wrote:
>
> I'm needing XmlMappin
Ehm... my fault... Should be Fixed now...
(try download it again, sorry)
Giacomo
On Fri, Apr 17, 2009 at 12:26 PM, wrote:
>
> I opened the whole project, and I could not detect the error.
> If you open the single System.Data.Linq project you will see that
> IEntityTracker.cs and DisableEntityT
Hi!
I'm needing XmlMappingSource: how can I move
src/DbLinq/System.Data.Linq/System.Data.Linq.Mapping/XmlMappingSource.cs in
a more appropriate location, without create problem to Mono's guys?
Giacomo
On Wed, Mar 25, 2009 at 3:15 PM, Jonathan Pryor wrote:
> On Wed, 2009-03-25 at 13:36 +0100,
2009 at 10:41 AM, Giacomo Tesio wrote:
> Wow! :-D
>
> Is equality comparer semantical or sintactical?
> I mean ((int) i) => i == ((int) p) => p
> or just ((int) i) => i == ((int) i) => i
>
>
>
>
>
> On Fri, Apr 17, 2009 at 10:35 AM, Giacomo Tesio
Wow! :-D
Is equality comparer semantical or sintactical?
I mean ((int) i) => i == ((int) p) => p
or just ((int) i) => i == ((int) i) => i
On Fri, Apr 17, 2009 at 10:35 AM, Giacomo Tesio wrote:
> Thanks a lot! :-D
>
>
> Giacomo
>
>
> On Fri, Apr 17, 2009 a
Thanks a lot! :-D
Giacomo
On Fri, Apr 17, 2009 at 10:25 AM, Pascal Craponne wrote:
> Hi Giacomo,
> it's all in the ExpressionEqualityComparer (in DbLinq.Util).
>
> The World :)
>
>
> On Fri, Apr 17, 2009 at 10:00, Giacomo Tesio wrote:
>
>> Hello Wor
Hello World! :-D
I need to know where ExpressionTree's evaluation is cached.
And actually I'd like to know how they are copared, since I've seen that
((int) i) => i == ((int) i) => i is always false (but may be I'm missing
something big).
Giacomo
--~--~-~--~~~---~--
801 - 900 of 1051 matches
Mail list logo
