Found in production codebase

Dinkus

Foo parentFoo =
GetFooFromDbById(parentFooId);<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

List<Foo> foos =
GetFoosFromDbByBatch(parentFoo.BatchId);<o:p></o:p>

<o:p> </o:p>

for (int i = 0; i <
foos.Count(); i++)<o:p></o:p>

{<o:p></o:p>

if (foos[i].Bar == parentFoo.Bar) continue;<o:p></o:p>

foos[i] = GetFooFromDbById(foos[i].Id);<o:p></o:p>

foos[i].Bar = parentFoo.Bar;<o:p></o:p>

SaveFooToDb(foos[i]);<o:p></o:p>

}<o:p></o:p>

nullptr

I pity da foos.

dhromed

Foos Do Rah!

Well, how else did you expect to UPDATE the Bars of Foos WHERE foo.parent = parentFoo?

IceDog

Well, this is the problem with using full ORMs. Doing mass updates or mass deletes is more trouble than it is worth. Micro-ORMs for the win.

Dinkus

Oh I wish this were using an ORM. These are POCOs that end up getting sent to a stored procedure to update the database. Looking past using for instead of foreach and then the fun continue in the loop instead of just inverting the if, but hitting the db again and mapping the results back into the object just to end up with what was already there is pretty inexcusable.

LevB

@Dinkus said:

the fun continue in the loop instead of just inverting the if

I do this, too, so that the code doesn't end up very indented.

Of course re-reading an existing object is a WTF.