Only One Reason to ever use Transient Properties in Core Data

  • After working through another issue caused by my use of a transient
    property, I just searched the whole Core Data Programming Guide for
    "transient".

    I found four disadvantages of using transient properties vs. one
    advantage.  The advantage is not having to write custom accessor
    methods to support non-standard data types.

    So my conclusion is that it is a design mistake to make "Transient" an
    attribute which is of a standard data type.  You get no advantages --
    only headaches, possible bugs, and "gotchas" when you switch from XML
    to SQLite store.

    Have I missed anything?

    Jerry Krinock

    (*) Here are the four disadvantages:

    ... you cannot fetch using a predicate based on transient properties...

    ... you cannot sort on transient properties using the SQLite store...

    ... with transformable attributes you specify just one attribute and
    the conversion is handled automatically. In contrast, with transient
    properties you specify two attributes and
    you have to write code to perform the conversion.

    ... If you use refreshObject:mergeChanges: with the mergeChanges flag
    YES, then any transient properties are restored to their pre-refresh
    value after awakeFromFetch is invoked. This means that, if you have a
    transient property with a value that depends on a property that is
    refreshed, the transient value may become out of sync.
  • I find transient attributes extremely useful sometimes for properties
    which you want in the undo stack, but not persisted to disk. For
    example data caches, or session-specific UI properties.

    Mike.

    On 20 May 2009, at 04:20, Jerry Krinock wrote:

    > After working through another issue caused by my use of a transient
    > property, I just searched the whole Core Data Programming Guide for
    > "transient".
    >
    > I found four disadvantages of using transient properties vs. one
    > advantage.  The advantage is not having to write custom accessor
    > methods to support non-standard data types.
    >
    > So my conclusion is that it is a design mistake to make "Transient"
    > an attribute which is of a standard data type.  You get no
    > advantages -- only headaches, possible bugs, and "gotchas" when you
    > switch from XML to SQLite store.
    >
    > Have I missed anything?
    >
    > Jerry Krinock
    >
    >
    > (*) Here are the four disadvantages:
    >
    > ... you cannot fetch using a predicate based on transient
    > properties...
    >
    > ... you cannot sort on transient properties using the SQLite store...
    >
    > ... with transformable attributes you specify just one attribute and
    > the conversion is handled automatically. In contrast, with transient
    > properties you specify two attributes and
    > you have to write code to perform the conversion.
    >
    > ... If you use refreshObject:mergeChanges: with the mergeChanges
    > flag YES, then any transient properties are restored to their pre-
    > refresh value after awakeFromFetch is invoked. This means that, if
    > you have a transient property with a value that depends on a
    > property that is refreshed, the transient value may become out of
    > sync.
  • On 2009 May 20, at 01:29, Mike Abdullah wrote:

    > I find transient attributes extremely useful sometimes for
    > properties which you want in the undo stack, but not persisted to
    > disk. For example data caches, or session-specific UI properties.

    Thanks, Mike.  I see the advantages you get from making them transient
    are --

    1.  Knowing that you saved your users a little hard disk space.
    2.  Not having to clear their values when the document is reloaded.

    Are there any other advantages?
  • On Wed, May 20, 2009 at 9:32 PM, Jerry Krinock <jerry...> wrote:
    > Are there any other advantages?

    Your desire for hard and fast rules disturbs me.  There are not
    distinct use cases for every technology.  Transient properties are
    useful for certain things, often as a component of some larger
    trade-off.  Why do you seek to establish concrete rules for when they
    are advantageous over non-transient properties?

    --Kyle Sluder
  • Jerry Krinock (<jerry...>) on 2009-05-20 9:32 PM said:

    > Thanks, Mike.  I see the advantages you get from making them transient
    > are --
    >
    > 1.  Knowing that you saved your users a little hard disk space.
    > 2.  Not having to clear their values when the document is reloaded.

    Why do you put "a little" in #1?  In my app, I use some transient
    attributes to store attributes that take many MB.  That's a substantial
    savings not to store them on disk.

    I sense that you dislike transient attributes. :)  FWIW, I find I use
    them rarely, for many of the reasons you've sited in this thread.

    Sean
  • On 2009 May 20, at 18:45, Kyle Sluder wrote:

    > Your desire for hard and fast rules disturbs me.  There are not
    > distinct use cases for every technology.  Transient properties are
    > useful for certain things, often as a component of some larger trade-
    > off.

    Thanks, Kyle.  I'm trying to identify the tradeoffs.

    On 2009 May 20, at 19:02, Sean McBride wrote:

    > In my app, I use some transient attributes to store attributes that
    > take many MB.  That's a substantial savings not to store them on disk.

    Ah, good.

    Conclusion:

    Don't just make an attribute "transient" because it can be derived
    from other persistent attributes.  Consider ...

    the advantages of making an attribute "transient":

    1.  For a nonstandard data type, to avoid having to write a custom
    accessor.
    2.  If its typical data size is huge, MB -- to save disk space.
    3.  Not having to clear its value when the document is reloaded, if
    that is required.

    and ... the disadvantages:

    1.  You cannot fetch using a predicate based on transient properties.
    (Although I've found that this may work with the XML store.)
    2.  You cannot sort on transient properties using the SQLite store.
    3.  With transformable attributes you specify just one attribute and
    the conversion is handled automatically. In contrast, with transient
    properties you specify two attributes and you have to write code to
    perform the conversion.
    4.  If you use refreshObject:mergeChanges: with the mergeChanges flag
    YES, then any transient properties are restored to their pre-refresh
    value after awakeFromFetch is invoked. This means that, if you have a
    transient property with a value that depends on a property that is
    refreshed, the transient value may become out of sync.
    5.  You may not get any warnings when you violate 1, 2 or 4.  Things
    "just won't work".  Having things break when switching from XML to
    SQLite stores is particularly annoying.
previous month may 2009 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Go to today