• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Design for "archiving" data in EOF
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design for "archiving" data in EOF


  • Subject: Re: Design for "archiving" data in EOF
  • From: Ken Anderson <email@hidden>
  • Date: Tue, 20 Jun 2006 09:53:14 -0400

Georg,

I have seem a couple of different ways of approaching this, from pretty simple, to crazy over the top.

A simple way is to have all of your objects inherit from an object that can textually serialize the changes made to your object. This works really well if the purpose of the history is for humans to read - not so great if you need to query it, etc.

I've built really complex auditing systems with EOF that work in a combination of database audit tables and definitions of new EOs that are the history counterparts of the real EOs. It's a little complicated, but I'll try to describe it:

- If you want to audit your EO, you create an aud_<tablename> table, and use triggers to populate the table when something changes
- You define EO's, like AudOrder and AudItem, that are subclasses (but not subentities) of the real class, so you can inherit all of the custom logic
- Your EOs all have a property like TransNumber, that can be used to identify the transaction they were created / updated in
- You define stored procedures that are used to fetch these EOs, which will determine whether to obtain the EO from the main or history table based on the TransNumber.


In the end, you have what I call a 'Retro-Cron Database'. It allows you to setup whatever entities you want to be audited, and you can then setup relationships between audit and non-audited EOs. Of course, there are tons of details I've left out, but the point is - it's possible to build something pretty amazing.

Ken

On Jun 20, 2006, at 8:29 AM, Georg von Bülow wrote:

Hi Mark,

thanks for your advice! Of course your suggestion would be a perfect
solution for the example I have given.
Actually I wanted to resolve it in a more generic way. Like, to configure
entities in EOModeler in UserEntries adding a property "archiving=true".
When I change some attributes and call saveChanges(), I would check this
property in runtime and then decide if I "archive" the entity or just
treat them normally.


Greetings,
Georg

Hello Georg,

This may not be appropriate for your entire problem, but for the
example you've given, I think I would just model it to take
examination versions into account.  Something like:

	Exam -->> ExamVersion -->> Question

Having:

	ExamVersion -->> StudentExam  -->> Answer

and:

	Answer -> Question

Then you could build in some mechanism for duplicating an exam to
create a starting point for a new version.  So each exam a student
takes is tied to a version, which itself won't be modified, just new
versions added as necessary.

Hope this helps!

Regards,
Mark

On Jun 19, 2006, at 10:02 AM, Georg von Bülow wrote:

Hi,

I am facing a general design problem in EOF, maybe someone has already
thought about it and could give me some hints.


I´m trying to implement a way of keeping track of "historic" data
in the
database with WebObjects.
That is, each time some data are changed, I would like to keep a
copy of
the old data with a status "historic" in the database, and insert
the new
(altered) data with status "active" in the database, instead of
overwriting and saving.

To illustrate the idea let me give a simple example.
I have an application with "examination results" of students.
These examinations were obtained through a questionnaire, which
consists
of many questions. If later I want to modify a question (or delete
one or
add a new one) for a future examination, I would like to archive
the old
questionnaire with its questions. Like this it is possible to
reproduce an
examination with its "historic" questionnaire and questions.

So I want to make a historic backup when:
one question is changed, one question is added, one question is
removed, a
questionnaire is changed etc...

I tried to implement this desired feature in EOF in a general way. My
dream would be to have some kind of *framework* which I could
always add
(with a minimum of necessary adaptations) to already existing
applications, introducing the possibility of archiving data.


Here is the approach I have taken so far:
Entities who should be archived will obtain a field "archivestatus"
which
could be "active" or "historic".
I use my own extended EOEditingContext. To pick up only active data
when a
fetch is made, I overwrote objectsWithFetchSpecification() adding a
qualifier with "status = active", in case the entity can be archived.


Then, when I want to save changes of a "question", I interfere in
saveChanges() of my EditingContext.
I have to make a copy of the altered question and its relating
objects. (I
use the copy()-method implemented in "Practical WebObjects", which
always
copies the whole "cycle" of related objects). The new objects are
set to
"active" and the old ones "historic".

Now if I remove or add one question it becomes messier. I would
have to
interfere in removeObjectFromBothSidesOfRelationshipWithKey(),
not to mention the complications when you add some objects and change
others at the same time and then call saveChanges()...


Anyway, I feel that it´s getting much more complex than I would have
liked. I have some doubts if I´m going in the right direction at
all, or
is it just a too dangerous way to interfere like this in EOF!?
Maybe there is a clever pattern using EOObserverCenter?

Hope I have made clear enough my problem and how I tried to
approach it.
Any advice and comments are appreciated!


Greetings, Georg

--------------------
Georg von Bülow
email@hidden

Niterói - Rio de Janeiro - Brasil




--------------------
Georg von Bülow
email@hidden

Niterói - Rio de Janeiro - Brasil

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Design for "archiving" data in EOF (From: Georg von Bülow <email@hidden>)
 >Re: Design for "archiving" data in EOF (From: Mark Morris <email@hidden>)
 >Re: Design for "archiving" data in EOF (From: Georg von Bülow <email@hidden>)

  • Prev by Date: Re: Design for "archiving" data in EOF
  • Next by Date: Re: Design for "archiving" data in EOF
  • Previous by thread: Re: Design for "archiving" data in EOF
  • Next by thread: Re: Design for "archiving" data in EOF
  • Index(es):
    • Date
    • Thread