Open Molokai opened 12 years ago
Thanks for reporting this issue. I'll try to get it fixed in 0.15, which should be done in the next week.
Mark
Moved to Issue #143
Would natural joins work - if I used the not-so-pretty syntax to set up the relationships?
Yes, and the call in your code under test could still use the explicit join; it gets ignored by InMemory at the moment.
I'm working on GiveCRM and the following doesn't appear to return anything for "FacetValueId", "FacetId" or "FacetValueValue":
var query = db.Facets.All()
.Select(
db.Facets.Id,
db.Facets.Type,
db.Facets.Name,
db.Facets.FacetValues.Id.As("FacetValueId"),
db.Facets.FacetValues.FacetId,
db.Facets.FacetValues.Value.As("FacetValueValue"))
.OrderBy(db.Facets.Id);
Does this have any bearing on this issue or is it a different one?
It's all part of the same issue, and will be fixed soon... honest...
Cool. I've added the NUnit IgnoreAttribute to our failing integration tests on GiveCRM for now so when this fix is available I'll do an update and try to revive them.
"where...in" constructions also don't seem to work with the InMemoryAdapter. Is this related?
E.g. .FindAllByX(1)
filters correctly, but .FindAllByX(new[] { 1 })
returns nothing.
Hey Mark, do you have an idea on how to fix explicit joins in the InMemoryAdapter? I need it to work as well, and am willing to put in what time I can to get it fixed. Just need to know where to start and how you think it should be done.
So I ran into this on the .19 release, was this ever resolved in one of the 1.0+ pre-releases? Or is this something that was offset until the 2.0 release?
I have tried running joins with the database.User.Query().Join(database.Department).On().Select() syntax (where the columns to join on are specified, since there is no referential integrity with the InMemoryAdapter). The query returns data, but not joined data as far as I can tell.
All the selected fields from the Department table are null, and the number of rows returned are the number of rows in the User table. If I switch so that the first table is Department, then all the User fields are null and the number of rows is the same as in the Department table.
This was tested with 0.14.0.1