Re: OO vs. RDB challenge

From: Kurt (kurbylogic_at_hotmail.com)
Date: 03/24/05 

Date: Wed, 23 Mar 2005 19:53:06 -0700

"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
news:3aekn7F6aj1v3U1@individual.net...
> Kurt wrote:
>> "Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
>> news:3ade5bF65ltsrU1@individual.net...
>>
>>>Kurt wrote:
>>>
>>>>>First fix your broken code and only after that take a grand standing
>>>>>with such pompous statements.
>>>>
>>>>
>>>>Ah yes, I suppose I intentionally omitted the *complex* part right? it
>>>>was nearly 4 am when I coded that, thankfully because there is some
>>>>encapsulation I can fix my solution without changing the client.
>>>>Add the following before groups.Remove(group)
>>>>foreach(user in users)
>>>> if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group);
>>>>And likewise for RemoveUser but looping over groups instead, clearly not
>>>>complex, I think you can handle it.
>>>>
>>>>I suppose now after pointing out how you only need 35 lines of code you
>>>>are going to make a big deal over these 6 extra statements huh?
>>>>However I was making the solution far more complex last night then it
>>>>needed to be. Your version doesn't provide any encapsulation why should
>>>>mine?
>>>>Since it will probably take me longer to explain I might as well just
>>>>write the alternate 20ish lines of boring code:
>>>>
>>>> public struct Policy
>>>> {
>>>> static Policy policy;
>>>> public static Policy Current
>>>> {
>>>> get { return policy; }
>>>> set {
>>>> foreach(UserGroupAssignment ug in value.usergroups)
>>>> if ( Array.IndexOf(value.users, ug.user) < 0 ||
>>>> Array.IndexOf(value.groups, ug.group) < 0)
>>>> throw new ApplicationException();
>>>> policy = value;
>>>> }
>>>> }
>>>>
>>>> public string[] users;
>>>> public string[] groups;
>>>> public UserGroupAssignment[] usergroups;
>>>> }
>>>> public struct UserGroupAssignment
>>>> {
>>>> public string user;
>>>> public string group;
>>>> }
>>>>
>>>>Okay guess thats about 15, about the same as your table creation script
>>>>(dynamic languages that don't require strong types would reduce this
>>>>further, only 5 of these lines actually do anything at runtime).
>>>>Clearly there is not alot of code required, none of which is complex.
>>>>Many developers have more difficulty understanding how to use a SQL join
>>>>then how to use foreach loops, I'm sure you disagree but clearly neither
>>>>solution is *complex*.
>>>>
>>>>How much further do you intend to insert foot in mouth?
>>>>
>>>>- Kurt
>>>
>>>
>>>More broken code, Kurt ?
>>>
>>>Not to mention that even if you fixed it somehow it wouldn't even begin
>>>to remotely address the constraints of my challenge.
>>
>>
>> Mine does not require cascading deletes to maintain concistancy, yours
>> does.
>
> You call that a feature ? Shifting complexity to the client context
> instead of simply declaring a ON CASCADE DELETE.

Okay, I can accept that, add back in the remove user/remove user functions.
You've shifted thread-saftey and deadlock prevention to the client, fix
yours.

>
> Your code does not maintain any kind of consistency. SQL can surely do
> that as well, even a high-school student writing his first program in
> Basic can do that, no problem.
>
>> SQL cannot perform a simple yet arbitrary regular expression search, my
>> client can.
>
> Yes, you can say that incompetent trolls don't know how to use regular
> expression in SQL queries. Hardly a problem attributable to SQL

Write me a query that will find all groups which have a that have a have the
same word or phrase more then once, first without () then within paren:
"Accounting (Accounting)" this was an error in an import script so we want
to remove these, however "Billing (Accounting)" is okay.

>
>> Yours does not always provide *better* then linear time. The overhead of
>> your non-existent solution in more practical scenario is likely to be
>> greater then mine, perhaps if you create an executable application that
>> actually performs the operations you say are "possible" we can compare
>> performance instead.
>
> Well, sure you can complainn that the overhead of DBMS being out of
> process but that disappears when you use embedded SQL libraries if you
> really need to. However, the trade-off of a real DBMS is that the same
> information can be easily and safely accessed by different processes.
> This discussion has nothing to do with you bailing out from the
> requirement to provide a better than linear search time.
>

Fix yours.
I can replace my string[]s with a (out-of the box) collection that uses
b-tree, its not that hard, I promise.

>> Your table creation script does not ensure "thread-safe" and
>> "deadlock-safe" usage, this is something your client (not included) must
>> do (deadlock detection is not deadlock safe rather only strengthens my
>> argument that can and do happen in a database)
>>
>
> Actually if you want to play with words you can play, but the ridiculous
> quality of your code is still left behind.

You mean the ridiculous simplicity, yours provides no encapsulation, why
should mine?

>
> Yes, users can sometimes deadlock each other by requiring access to
> resources in all kinds of orders. Transaction can fail for one reason or
> the other, including an overzealous database server. This is inherent to
> any distributed system. Software systems need to deal gracefully with all
> kinds of failures, cause the mechanism to write perfect software that
> never fails has not been invented just yet.
>
> The difference is that with a DBMS one transaction is rolled back, overall
> progress is being made, data is left in a consistent state. The system
> overall is never deadlocked.
>
> With the typical mistakes that happen everyday when OO developers write
> concurrent software the choice is between :
> 1) a deadlock without user recourse, sometimes even paralyzing the whole
> system
> 2) inconsistent data.
> 3) have developers that write perfect software
>
> Your code in both solutions avoids the deadlock by choosing to expose
> users to inconsistent data.

Wrong, Policy.Current is always valid, modifications to that object cannot
affect another user until Policy.Current is replaced, the new policy is
ensured by to be valid by the property set method.

>
>
>> Fix your code then I will "fix" mine.
>>
>> - Kurt
>>
>
>
> If you don't fix it, then I guess there's nothing left to discuss.

When you withdrawl your assumption that your code satisfies all of these
constraints and fix your code, then I will fix mine.

- Kurt

Relevant Pages

  • Re: OO vs. RDB challenge
    ... >>More broken code, Kurt? ... expression in SQL queries. ... users can sometimes deadlock each other by requiring access to ... cause the mechanism to write perfect software ...
    (comp.object)
  • Re: URGENT deadlock question
    ... I have a deadlock template that I use with the following ... > SQL: Statement Completed ... > "Trace flags remain enabled in the server until disabled by executing ...
    (microsoft.public.sqlserver.server)
  • Re: Analyzing Error log with Trace Flag 1204 turned on
    ... I have read the appropriate section out of Inside SQL ... up to a deadlock only from the spids involved in the deadlock? ... > resources in Inside SQL Server 2000, and in my ebook on Troubleshooting ... Are they locks currently held or ...
    (microsoft.public.sqlserver.server)
  • False SQL Deadlock Messages?
    ... We started getting large number of deadlock messages on some rather simple ... SQL receive ports. ... To complicate matters the event log message, shown below, shows the schema ...
    (microsoft.public.biztalk.general)
  • Re: [PATCH] kdesu broken
    ... unless you take signals - we can't block signals or it can all deadlock. ... but the only way I can see to fix the ... world cases and we are standards compliant perhaps we are trying too ...
    (Linux-Kernel)