... During the conversion -- or at worst, during testing of the conversion -- these things should be identified and may be resolved. Bear in mind that you reMessage 1 of 49 , Nov 14, 2003View SourceOn Fri, Nov 14, 2003 at 08:36:25AM +0000, Frugal wrote:
>During the conversion -- or at worst, during testing of the conversion
> <quote who="STILES, BRAD">
> > Names may be identical, ID's should not. Just because the name of both is
> > "Arcane Master" doesn't mean that the ID will be. If that means that all
> > .MODs, etc, need to be keyed on the ID rather than the name, then do be
> > it.
> > In practice that likely means that some method of determining the key will
> > have to be in the UI, along with possibly a method for entering the .MODs
> > themselves.
> My original question regarded automaticlly coverting the data from LST to
> The problem as I see it is this:
> Publisher A has a feat 'foo'
> Publisher B has a feat 'foo'
> Publisher C expands on the feat 'foo' from publisher A.
> when we convert do we have :
> <feat id="feat.foo" />
> <feat id="feat.foo" />
> <feat trans="modify" id="feat.foo" />
> At which point we have 2 objects with the same ID.
-- these things should be identified and may be resolved.
Bear in mind that you're asking how to automatically solve a problem
that evidently already exists in the data (two things of the same type
having the same name, but different definitions). This is not
introducing the problem.
> Or do we have:Don't do this. You'll end up with a needless repetition of objects with
> <feat id="a.feat.foo" />
> <feat id="b.feat.foo" />
> <feat trans="modify" id="c.feat.foo" />
> At which point the modded feat from C will never affect anything.
crappy IDs. I don't want to have to remember where something came from
all the time, and I don't want to have fragile IDs that will either
break or be incorrect if a superseding definition is released, or the
original source goes away (for some reason; I don't think they would).
Putting the source in the ID, unless necessary, is to me a lot like
Hungarian notation when programming. It's of minor help at times, but
becomes either a pain in the ass to work with or even outright incorrect
during maintenance (what used to be 'iSomething' gets changed to a
float; do you leave it as is so you don't break a bunch of code --
thereby having it lie to the reader -- or change all of them to
'fSomething' so it is correct, but potentially touches a lot of code?
Both suck. Call it 'something' and be done with it.).
Keith Davies "Your ability to bang your head against
keith.davies@... reality in the hope that reality will
crack first is impressive, but futile"
-- Geoffrey Brent, rec.games.frp.dnd
... Yep. Serious ones. Go take a look at how we manage things in pcgen currently. There are no primary keys, and we analyze strings likeMessage 49 of 49 , Nov 23, 2003View SourceOn Nov 14, 2003, at 3:47 PM, Brass Tilde wrote:
>> On Friday 14 November 2003 20:03, Brass Tilde wrote:Yep. Serious ones. Go take a look at how we manage things in pcgen
>> We currently have >6Mb of data files... 30,000 lines so
>> probably 25,000 items
> And you had performace problems with that tiny little thing? One of
> tables in our main database, constantly transacted against, currently
> over 4 million rows. Several others have in excess of a million. That
> doesn't count the ancillary databases used for non-Core operations. No
> primary keys *really* sucks in that environment.
currently. There are no primary keys, and we analyze strings like
"Foo|BAR|fizBot|PREQ:STR>3:Green" with a string tokenizer on "|" and
then several more on ":" to see whether we should show something in
green or bold, then eval the prequisite (stored in string form) to see
if the character meets it, and thus should be show in red.
Last time I checked, showing the feat screen with just the Big 3 and
Monte's ranger requires running something like 85,000 strings through a
bonus checker. I believe that some optimization work has been done
since then, but we have not set up real dependencies between objects,
partially because of a lack of keys, and thus we end up re-doing a lot
of work on tab display.
This technique was not a bad one when we had just a few items, with
relatively simple formulas, but we now have zillions of them. Having
unique ids and objects would make it really, really easy to find
objects by key, so we could then parse the formulas only once and
evaluate them as needed without lots of code knowing the difference.
If all we do is provide a unique id that can be used in maps/sets for
object lookup, and get all the refs hooked up right. we will have done
a good thing. If we also parse the formulas once, we will cause
probably three or four orders of magnitude improvement in
display/calculation speed. As a bonus, we could determine those things
to be drawn in a given font/color and paint those, which can result in
three orders of magnitude improvement in draw time on MacOS X.
(Changing fonts/colors is pricey, as it goes through a compositor.)