Re: OO vs. RDB challenge
From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 03/24/05
- Next message: Kurt: "Re: OO vs. RDB challenge"
- Previous message: Kurt: "Re: OO vs. RDB challenge"
- In reply to: Kurt: "Re: OO vs. RDB challenge"
- Next in thread: Kurt: "Re: OO vs. RDB challenge"
- Reply: Kurt: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 23 Mar 2005 17:50:30 -0800
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.
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
> 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.
> 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.
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.
> Fix your code then I will "fix" mine.
>
> - Kurt
>
If you don't fix it, then I guess there's nothing left to discuss.
- Next message: Kurt: "Re: OO vs. RDB challenge"
- Previous message: Kurt: "Re: OO vs. RDB challenge"
- In reply to: Kurt: "Re: OO vs. RDB challenge"
- Next in thread: Kurt: "Re: OO vs. RDB challenge"
- Reply: Kurt: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
