harmonyhacks / dahlia Goto Github PK

We need a couple more bed codes added to the list, and also fix the ones that have a extra single-quote on the end of them. I'll get the codes to add in a few minutes

Several questions around adding and reassigning participants came to mind:

• The global reassign search box at the top of the page is not hooked up correctly yet
• Searching for and selecting a participant in the Add Participant view adds them to the new retreat but doesn't remove them from any previously-registered or previously-waitlisted retreats. What's the intended behavior here?
• Do we support having one participant registered for multiple retreats simultaneously?
• If the user adds a participant, deletes the participant, then later goes to add them again, we'll end up with two participant records in the db. Should the Add Participant page warn if there's already a match in the db?

When adding a participant to a retreat, we don't display bed codes that are already assigned. However, we apparently don't display bed codes that are assigned for any retreat, which is a bug.

Can we have a way to set up a dev database and such when we're outside the building? If we want people to work on this remotely, they'll need a way to test the site.

Two participants should not be able to be assigned to the same bedcode for the same retreat.

1. Create a retreat with a waitlisted participant
2. Generate a report for the retreat.

Null reference exception.

Commenting out lines is a little too hard for lazy belly-button-cheetos-eating developers. How about a config file setting? cbilson/Dahlia@cf3d14e1f3902975e454

Can someone please review and sign off?

Having the database file checked in is seriously killing me. Half the time SQL Express has the file locked so Git can't touch it, and the other half of the time Git is staging it for me when I don't want to commit it. Is there some best practice around this that I don't know about?

Now that we have auto-migration when the app starts up, can we maybe remove the .mdf file from the repo? New developers would have to manually create Dahlia.mdf through Visual Studio (right-click on App_Data folder, Add New Item, SQL Database) but then the schema would be automatically created when they ran the app.

Comments?

I've been thinking that we have some domain modeling issues around registrations, and our inpromptu design review with Corey Haines this afternoon plus my work on editing participants tonight confirmed it.

Currently we have a controller for retreats, and a controller for participants, but no controller specifically for registrations. This leads to wonky stuff like ParticipantController.AssignToRetreatChooseBedCode where we're trying to shoehorn registration stuff (i.e. choosing a bed code) into a place where it doesn't belong.

Tonight I implemented ParticipantController.Edit and was feeling pretty good about myself until I realized that it just edits the participant and doesn't allow you to edit the bed code for a retreat. Doh.

I'm not sure exactly what it ought to look like but somehow we need to more clearly express the idea that the user can take actions on retreats (add, edit, remove), take actions on participants (add, edit, remove), and take actions on retreat registrations (register the participant for a retreat, change the participant's bed code, and remove the participant's registration). It's a little bit complicated by the fact that some of those actions should be combined in the UI (i.e. create a participant, register the participant, and assign a bed code should be one screen). Until we fix this the code is going to get more and more gnarly.

We should give a go of doing a lunch hack session again.

What say you @Ang3lFir3, @codereflection, @NotMyself, and @TerryHughes?

I'd like to have required db data (like the bed code list) automatically inserted into the database whenever NHibernate rebuilds the schema rather than having to remember to run a SQL script.

I know how to do that with EF 4 Code First but I don't know how to do it with NH, and a cursory web search didn't reveal any examples. Anyone done this before and know the most correct way to do it?

As I understand the usual workflow, Victrina will often assign a participant to multiple retreats at once, where the participant is registered (has a bed) for their primary choice and is waitlisted for their other choices. Because participants often have to change their plans, Victrina would like to be able to search for a participant, go to a page that lists all of the participant's retreats (both registered and waitlisted) and change the bed assignments from there. Do I have that correct?

I'm probably going to work on this soon unless someone else wants to claim it first.

I get the following error when starting the app up:

An attempt to attach an auto-named database for file C:\code\Dahlia\src\Dahlia\App_Data\Dahlia.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.

I don't have Dahlia.mdf at that location... should I?

1. Add a person to a retreat waitlist (add participant without bed code).
2. Add another person to the waitlist.
3. Get a 500 error.

Right now retreats have a list of registrations. Each registration may have a bed code if the participant has been assigned a bed (and is therefore officially registered) or a null bed code if the participant is on the waitlist for the retreat. This works ok but it's already caused multiple bugs in the code where we didn't expect bed codes to be possibly null.

Rather than having to test and protect against null bed codes all the time it would probably be better to have an explicit waitlist in the domain model which is just a joining of participants and retreats without any bed code at all. On the negative side, you'd need to deal with both collections if you want to display a unified list of both registered and waitlisted participants, but on the positive side the intention would be more explict and there would be fewer opportunities for bugs.

I'm going to work on this shortly unless someone else has a better idea.

1. Create a retreat.
2. Add two participants.
3. Delete one participant.

Result:
Cannot insert the value NULL into column 'Retreat_Id', table 'C:\PROJECTS\GITHUB\DAHLIA\SRC\DAHLIA\APP_DATA\DAHLIA.MDF.dbo.Registration'; column does not allow nulls. UPDATE fails.
The statement has been terminated.

Not sure how to fix that at the moment. NH apparently thinks its a good idea to just null out the FK field on the registration row rather than delete it altogether, but I don't have much experience with NH and don't know how to convince it otherwise.