I have a user requirement to design a search screen that has various fields from various entites, any one or more of which may have a value filled in. This will then formulate a query and return the results. It's in the formulation of the query that I have a question. So far I've created a control for each entity inheriting from my standard text box that has a FieldIndex property which allows me to tie the text box to an entity field, for the purposes of constructing the predicate. The next step of course is to add the relationships between the fields that I've added to the predicate bucket and that's where I'm a little stuck. Has anyone done something like this where you're determining the joins between your entities programatically? I'm always trying to return the same result set so I have a static start point.

Any thoughts or suggestions would be appreciated.

Thanks.

It's a little bit hard to answer your question in full without a little more information.

However, what you are talking about is certainly possible. It becomes more complex as the number of related entities becomes more complex, or if there are different starting points.

The easiest path would be to just include ALL the relations. But I assume that this would be too inefficient, otherwise you wouldn't have asked the question.

I also assume that you are only returning fields from the main (starting point) entity? Otherwise you need all the relations anyway. You said that the resultset was always the same.

So, assuming you have a static starting point of one entity, as you've said, and a number of possible relations to it, you could do something like (pseudocode!):

//Assuming you have three entities:
//EntityMain
//EntityRelated1
//EntityRelated2

bool requiresRelation1 = false;
bool requiresRelation2 = false;

//any time a predicate is used on a related entity, set that entity flag to true
if (txtFieldAOnEntityRelated1 != "")
{
//create and add the predicate here
requiresRelation1 = true;
}

if (txtFieldBOnEntityRelated1 != "")
{
//create and add the predicate here
requiresRelation1 = true;
}

if (txtFieldAOnEntityRelated2 != "")
{
//create and add the predicate here
requiresRelation2 = true;
}

if (requiresRelation1)
{//create relation to EntityRelated1 here}

if (requiresRelation2)
{//create relation to EntityRelated2 here}

I hope that helps. It's possible I'm not understanding the question completely.

I'm from Chicago too--where in Chicago are you from?

Thanks psandler. I had thought of something like what you describe, however I was trying to avoid having to write specific code to handle each of the entities. If I want to add an entity in the future it would be nice to just handle it without code change (at least in this area).

I had started down the path of having my relationships stored with each of my controls, and thus available for adding when there's a value in that control, and this is marginally more appealing, however I found that LLBL will happily add the same relationship twice and then throw an exception. So I figured I'd remove the relationships first and then add them, however I can't remove a relationship from a RelationPredicateBucket - even one that I know to be in the bucket - without getting an exception. I'm not sure what I'm doing incorrectly, and I'm about to add another thread about this if I can't find any info.

Chicago: The greatest city on earth (or at the very least in the US...). I live in Andersonville and work in Hoffman Estates

ChicagoKiwi wrote:

Thanks psandler. I had thought of something like what you describe, however I was trying to avoid having to write specific code to handle each of the entities. If I want to add an entity in the future it would be nice to just handle it without code change (at least in this area).

I had started down the path of having my relationships stored with each of my controls, and thus available for adding when there's a value in that control, and this is marginally more appealing, however I found that LLBL will happily add the same relationship twice and then throw an exception. So I figured I'd remove the relationships first and then add them, however I can't remove a relationship from a RelationPredicateBucket - even one that I know to be in the bucket - without getting an exception. I'm not sure what I'm doing incorrectly, and I'm about to add another thread about this if I can't find any info.

Ah, I see.

I can't verify this possibility, because I don't have access to my dev machine right now.

However, you could add the relation to a hash table if the control has a value. Each time you do this, ensure that the value isn't already in the hashtable--if it's already there, don't add it.

Then just cycle through the hash and add each relation that's in it. Seems to me that would work, assuming you already know how to "store the relation with the control"?

ChicagoKiwi wrote:

Chicago: The greatest city on earth (or at the very least in the US...). I live in Andersonville and work in Hoffman Estates

Yikes! Is that like 90 minutes each way? I live in Lakeview and work in the Loop.

psandler wrote:

Ah, I see.

I can't verify this possibility, because I don't have access to my dev machine right now.

However, you could add the relation to a hash table if the control has a value. Each time you do this, ensure that the value isn't already in the hashtable--if it's already there, don't add it.

Then just cycle through the hash and add each relation that's in it.

I agree but it seems like double work to add them all to a hash table just so that I can get a unique list which I then extract and add to the bucket. I know they're different but the hash table and the bucket would essentially be doing the same job...

psandler wrote:

Seems to me that would work, assuming you already know how to "store the relation with the control"?

I think what I'm going to do is let the LLBL code emitter build my base controls and then modify them to add the relationships required. It's not pretty but I can't really come up with a better way.

psandler wrote:

ChicagoKiwi wrote:

Chicago: The greatest city on earth (or at the very least in the US...). I live in Andersonville and work in Hoffman Estates

Yikes! Is that like 90 minutes each way?

I go early and leave early so I usually only spend 45 - 60 mins but that's quite enough!

psandler wrote:

I live in Lakeview and work in the Loop.

Nice! I'd love to have Charles T. Anderson take me to work...

Email me at simon underscore beets at adp dot com if you feel like it

It's a bit hard to find a generic way to find back a relation. The relations are now produced in code through properties, for that reason. You can write a template easily (based on the template which produces the relations classes) which adds all relations to a hashtable or other construct and which you then use to retrieve the relations.

First, find the relations for a given entity. Then find the relation for the given end entity, then, find the relation for the field in start entity and the field in end entity (or fields).

Is there a reason why the following code consitently give me an error? It doesn't seem to matter the relationship I add, and obviously the code it only for testing, but I presume I'm doing something wrong.

filterbucket.Relations.Add(MyProjectEntity.Relations.SubprojectEntityUsingProjectId)
filterbucket.Relations.Remove(MyProjectEntity.Relations.SubprojectEntityUsingProjectId)

Which error do you get?

That remove is doing a simple instance check. As EntityCollection doesn't implement Equals, the Remove wont do a thing in that form. This will:

EntityRelation er = MyProjectEntity.Relations.SubprojectEntityUsingProjectId;

filterBucket.Relations.Add(er);

//...

filterBucket.Relations.Remove(er);

Sorry for the lack of reply. Yes - that was the problem I was having.