• 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: Journaling join tables
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Journaling join tables


  • Subject: Re: Journaling join tables
  • From: Ray Kiddy <email@hidden>
  • Date: Sun, 24 Jun 2007 20:48:57 -0700


On Jun 21, 2007, at 9:12 AM, Kurt Werle wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

We have subclassed EOEditingContext so that it records which Person
is logged in to our application.  Whenever an EO is saved/inserted,
that Person is recorded as the updater of that row (from the ec's
saveChanges()).  We have journaling turned on in Oracle, so this all
gives us a nice journal of who did what with what data.
The problem is in the join tables.  We would like to set the updater
in the join tables, but EOF does that very much behind the scenes.
Ideally, we would like to add this information without making the
join tables "proper EOs", because we enjoy having them work
automagically for us.  Yes, this means we want to put data into the
joins that EOF will not see unless we model it later (or in a
different model).

Anyone have any suggestions on how we might be able to do this?

Thanks,
Kurt

I do not know if anyone will think this is a good idea but I just created a command-line EOF app to experiment with this, and it did work, so since you ask....


Since you are talking about join tables, I assume you are talking about many-to-many relationships. And I am not sure what kind of information you want to attach, but I think that it does not matter.

This is what I just checked:

I created entity A and B with a many-to-many relationship between them so I now have join entity C. I added a "name" column to this table and created an entity D pointing to the same table as C.

So, entity A has attributed aID, entity B has attributed bID and name, C has attributes: aID, bID. D has attributes aID, bID, name.

In my first editing context, I created a new A object and a new B object and linked them to each other. This created one C entry. I got the primary key value of the new A and the primary key value of the new B. using the EOUtilities method.

Then I created a new editing context, ec2. I then did a search on objects in entity D using the 2 primary keys. In other words, I created a dictionary with "aID" and its value, and "bID" and its value and used the objectWithPrimaryKey method in EOUtilities to search for an object of entity D. I then set the name of that join object.

I was still able to use the join with no problems in the first editing context.

So, I believe that as long as you do not expect any of the new information you add to the join object with the second editing context to be visible in the first editing context, you are fine.

The main point is that the only information about the join table that is known by both editing contexts is the aID and bID attribute values. Those will not change. If you change any other attribute of entity D, any object of entity C will not behave any differently. Does this make sense?

I could share the code if necessary, but it is a hack and it literally does just what I say here.

- ray


_______________________________________________ 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
  • Follow-Ups:
    • Re: Journaling join tables
      • From: Kurt Werle <email@hidden>
References: 
 >Journaling join tables (From: Kurt Werle <email@hidden>)

  • Prev by Date: Keep WebObjects, Remove cgi-bin
  • Next by Date: Re: Java Client : who is using it ?
  • Previous by thread: Journaling join tables
  • Next by thread: Re: Journaling join tables
  • Index(es):
    • Date
    • Thread