<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="midad69ab690503181515875110f@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, 18 Mar 2005 17:43:42 -0500, Daniel Salama <a class="moz-txt-link-rfc2396E" href="mailto:dsalama@user.net"><dsalama@user.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">db root at: 'people' put: people.
db root at: 'lastNames' put: lastNameIndex.
person := Person new; firstName: 'Daniel'; lastName: 'Salama'.
people at: 'some_magical_key_like_an_oid' put: person.
lastNameIndex at: (person lastName) put: person.
db commit.
Basically, I create one person object and store it twice in the
database. However, from your previous answers, only one instance of the
object is actually stored. The other one is simply a reference.
Are my assumptions correct? Is what I did correct?
</pre>
</blockquote>
<pre wrap=""><!----></pre>
</blockquote>
I'm jumping in kind of late and didn't read the whole thread (sorry).
I just want to add to Avi's comment. I have managed to get away with
very few "indices" in every Seaside app I've written. In fact, most
have only one or two such things. Users keyed by username is the only
one that appears in all of my applications. From the user I simply
navigate to the objects I want. Generally I don't find that I need to
search _large_ collections of things very often. For small collections
I just do things like:<br>
<br>
people detect: [:person | person lastName = 'Salama'] ifNone: []<br>
<br>
which works fine even in GOODS as long as the people collection is
small (<200 elements is my standard benchmark). Maybe this sounds
silly but most of the time you arrive at a collection by navigating
object relationships:<br>
<br>
self currentShopper orders detect: [....]<br>
<br>
so by the time you get to a leaf that's a collection there aren't many
items to search through. Basically I advise you to index only when
absolutely necessary (for the reasons that Avi's already given you).
And in those cases try to stick to indices with invariant keys since
maintaining and index whose keys change can really pollute your
persistent objects. Let me carry the order example further...if you
want to support customers with hundreds of orders you're done (its
already fast enough). If you need to deal with thousands of orders
then you begin studying your "detect:" blocks. What are your searches
based on? If its always the same invariant key change to a TSTree and
you're done. If you're searches vary widely consider refactoring your
objects. Finally, if refactoring doesn't seem warranted to support
this search, go with index maintenance. My extremely limited
experience is that you don't get that far very often.<br>
<br>
As Avi pointed out this is very different than the typical relational
approach where relationships are maintained through foreign keys. I
wouldn't ever, for example, need to index all of the orders in my
system on the name of the customer that owns the order. The
relationship is maintained in the objects themselves. Also, I would
also never (in Seaside) pass a foreign key of an object to a callback.
For example here's how I'd write a "choose your order" view (in
renderContentOn:):<br>
<br>
self currentShopper orders orderedListDo: [:order |<br>
html anchorWithAction: [self orderSelected: order] text: order
printString].<br>
<br>
Notice that I don't pass a key for the order to the callback, I pass
the order itself. This is very different from your typical
JSP/PHP/ASP/mod_perl/whatever application where your links carry keys
for objects, not the objects themselves. As an exercise I'd try to
create your application with almost no indices and follow the
prescription above. If you can't get the performance you need then
ignore my comments from now on :-)<br>
<br>
Again, I'm sorry if this was a repeat of a previous post. I hope there
is something usefull in it.<br>
<br>
David<br>
</body>
</html>