Re: Looping Search
This WebDNA talk-list message is from 2006
It keeps the original formatting.
numero = 66793
interpreted = N
texte = That is interesting and important for references in other tables. You could have the field for "inactive_on" and "created_on" as dates to get a sense of timing too. If the person_id is used elsewhere and still active (i.e. the record could be updated), you will need to factor in reassignment for those values in your business logic. Alex's method at least preserves the relationship until the reassignment is made. I would recommend not deleting, updating the subordinates and inactivating the record with a date field. It sounds like a transactional approach might also work. I know there was a transactional scriptfor webdna designed at www.genericaddress.com but I never looked at it. Back on the data structure, I just read last night about the "acts_as_tree" model method in Rails. That seems like it would work really well to handle the self-referential tree structure originally set out. Of course, you'd have to be using Rails first. -----Original Message----- From: Alex McCombie
Sent: Thu, 06 Apr 2006 09:30:47 -0400 To: "WebDNA Talk" Subject: Re: Looping Search In similar situation with staffing we handle it a bit differently. If someone 'leaves' their record stays in tact but is flagged as inactive. Then in your search you could use that flag to keep relationships and intelligently code around the inactive user. This becomes critical in many ways keeping all sorts of items across countless tables from being orphaned due to their original association with a no inactive staff. The inactive label gives you the infinite flexibility to show relationships clearly labeling the inactive staffer, or generate error reports about staff associations with that inactive record, or creating interfaces to reassign associations with a replacement staff. Even allows for temporary relationships based upon some pre-defined logic. In our world.... NEVER delete the staff record. Historical association is critical and should NEVER be lost. HTH Alex On 4/6/06 8:22 AM, "Clint Davis" wrote: > Thanks Bill. The threaded bulleting board analogy is exactly what I was > thinking. The reassignment scenario seems like the best approach. > > > On 4/5/06 4:40 PM, "devaulw@onebox.com" wrote: > >> This seems alot like a threaded bulletin board. >> >> So the problem is how to re-assign subordinates in the hierarchy when a >> supervisor disappears. >> >> One way might be to prevent deleting 2 until it's subordinates are >> re-assigned >> (i.e. throw up an error until the user fixes the condition). Not very >> friendly since it lacks an intelligent default. >> >> Another way is to reassign the subordinates upon deleting 2 via a default, >> i.e. 2 has a supervisor and when 2 is deleted, automatically assign everyone >> who reports to 2 to 2's supervisor. I think that's what you were proposing. >> Seems like a good solution too. Get 2's supervisor, search for anyone with 2 >> as a supervisor, replacefounditems with 2's supervisor. >> >> If an entry already has a missing supervisor [lookup =notfound], it needs to >> be flagged and a supervisor assigned. >> >> Bill >> >> >> -----Original Message----- >> From: Clint Davis >> Sent: Wed, 05 Apr 2006 15:10:58 -0500 >> To: "WebDNA Talk" >> Subject: Re: Looping Search >> >> I *do* have a field in the database where each person's immediate supervisor >> is listed. Right now, Person 1 is hard coded into the page. A [search] for >> anyone whose immediate supervisor is Person 1 yields the Person 2 listing >> and so on down the chain. This works unless someone at the top is removed: >> if Person 2 left, Persons 3, 8, and 11 would have to be reassigned to Person >> 1 as their immediate supervisor, or the whole chart would break. >> >> >> On 4/5/06 2:57 PM, "Pat McCormick" wrote: >> >>> Why not just have a field for immediate supervisor for every Person? >>> A demotion simply means changing the supervisor field. Or i guess it >>> could also mean coming to a stop. (get it? demotion? anyone?) >>> >>> >>> On Apr 5, 2006, at 2:24 PM, Clint Davis wrote: >>> >>>> I need to setup and org chart like this: >>>> >>>> Person 1 >>>> -----Person 2 >>>> ----------Person 3 >>>> ---------------Person 4 >>>> ---------------Person 5 >>>> ---------------Person 6 >>>> ---------------Person 7 >>>> ----------Person 8 >>>> ---------------Person 9 >>>> ---------------Person 10 >>>> ----------Person 11 >>>> ---------------Person 12 >>>> ---------------Person 13 >>>> ---------------Person 14 >>>> >>>> All of these people have a record in the personnel database with a field >>>> for >>>> their immediate supervisor. Can this be done with a [loop]'ed [search] >>>> versus >>>> my current nested [search]es? I don't want it to break if Person 3 gets >>>> demoted, for example. > > > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ -- Alex J McCombie Adventure Skies Interactive (ASI) Alex@Adventureskies.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
That is interesting and important for references in other tables. You could have the field for "inactive_on" and "created_on" as dates to get a sense of timing too. If the person_id is used elsewhere and still active (i.e. the record could be updated), you will need to factor in reassignment for those values in your business logic. Alex's method at least preserves the relationship until the reassignment is made. I would recommend not deleting, updating the subordinates and inactivating the record with a date field. It sounds like a transactional approach might also work. I know there was a transactional scriptfor webdna designed at www.genericaddress.com but I never looked at it. Back on the data structure, I just read last night about the "acts_as_tree" model method in Rails. That seems like it would work really well to handle the self-referential tree structure originally set out. Of course, you'd have to be using Rails first. -----Original Message----- From: Alex McCombie Sent: Thu, 06 Apr 2006 09:30:47 -0400 To: "WebDNA Talk" Subject: Re: Looping Search In similar situation with staffing we handle it a bit differently. If someone 'leaves' their record stays in tact but is flagged as inactive. Then in your search you could use that flag to keep relationships and intelligently code around the inactive user. This becomes critical in many ways keeping all sorts of items across countless tables from being orphaned due to their original association with a no inactive staff. The inactive label gives you the infinite flexibility to show relationships clearly labeling the inactive staffer, or generate error reports about staff associations with that inactive record, or creating interfaces to reassign associations with a replacement staff. Even allows for temporary relationships based upon some pre-defined logic. In our world.... NEVER delete the staff record. Historical association is critical and should NEVER be lost. HTH Alex On 4/6/06 8:22 AM, "Clint Davis" wrote: > Thanks Bill. The threaded bulleting board analogy is exactly what I was > thinking. The reassignment scenario seems like the best approach. > > > On 4/5/06 4:40 PM, "devaulw@onebox.com" wrote: > >> This seems alot like a threaded bulletin board. >> >> So the problem is how to re-assign subordinates in the hierarchy when a >> supervisor disappears. >> >> One way might be to prevent deleting 2 until it's subordinates are >> re-assigned >> (i.e. throw up an error until the user fixes the condition). Not very >> friendly since it lacks an intelligent default. >> >> Another way is to reassign the subordinates upon deleting 2 via a default, >> i.e. 2 has a supervisor and when 2 is deleted, automatically assign everyone >> who reports to 2 to 2's supervisor. I think that's what you were proposing. >> Seems like a good solution too. Get 2's supervisor, search for anyone with 2 >> as a supervisor, replacefounditems with 2's supervisor. >> >> If an entry already has a missing supervisor [lookup =notfound], it needs to >> be flagged and a supervisor assigned. >> >> Bill >> >> >> -----Original Message----- >> From: Clint Davis >> Sent: Wed, 05 Apr 2006 15:10:58 -0500 >> To: "WebDNA Talk" >> Subject: Re: Looping Search >> >> I *do* have a field in the database where each person's immediate supervisor >> is listed. Right now, Person 1 is hard coded into the page. A [search] for >> anyone whose immediate supervisor is Person 1 yields the Person 2 listing >> and so on down the chain. This works unless someone at the top is removed: >> if Person 2 left, Persons 3, 8, and 11 would have to be reassigned to Person >> 1 as their immediate supervisor, or the whole chart would break. >> >> >> On 4/5/06 2:57 PM, "Pat McCormick" wrote: >> >>> Why not just have a field for immediate supervisor for every Person? >>> A demotion simply means changing the supervisor field. Or i guess it >>> could also mean coming to a stop. (get it? demotion? anyone?) >>> >>> >>> On Apr 5, 2006, at 2:24 PM, Clint Davis wrote: >>> >>>> I need to setup and org chart like this: >>>> >>>> Person 1 >>>> -----Person 2 >>>> ----------Person 3 >>>> ---------------Person 4 >>>> ---------------Person 5 >>>> ---------------Person 6 >>>> ---------------Person 7 >>>> ----------Person 8 >>>> ---------------Person 9 >>>> ---------------Person 10 >>>> ----------Person 11 >>>> ---------------Person 12 >>>> ---------------Person 13 >>>> ---------------Person 14 >>>> >>>> All of these people have a record in the personnel database with a field >>>> for >>>> their immediate supervisor. Can this be done with a [loop]'ed [search] >>>> versus >>>> my current nested [search]es? I don't want it to break if Person 3 gets >>>> demoted, for example. > > > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ -- Alex J McCombie Adventure Skies Interactive (ASI) Alex@Adventureskies.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
devaulw@onebox.com
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
hierarchy question... (2000)
Not reading code (1997)
RE: [WebDNA] Windoes Server2008 users? (2011)
Just a thought (1998)
Saving Text Areas with Orders (1997)
all records returned. (1997)
WebMerchant when CC network is down (1998)
all records returned. (1997)
Grep to convert characters to html entities (2006)
Help name our technology! (1997)
What am I missing (1997)
[URGENT] Different Results From Math Tag Depending On OS (2006)
case sensitivity in lookups (1997)
ThisURL (2000)
problems with 2 tags (1997)
Protect and Serve (1999)
IIS4b2 and WebCatalog b19 (1997)
suffix mapping for NT? (1997)
Auto SKU's (2000)
Can you do this??? and other stuff (1997)