If your model is setup to cascade delete the relationship, it should.On May 3, 2006, at 5:52 PM, WebObjects wrote: David and others, thanks soooo much. Here is the winner:
if (donor.entityName().equals("TblDonor")) {
String tempLName = (String)donor.valueForKey("strLastName");
System.out.println("This is the last name I found: " + tempLName);
}
...I greatly appreciate the help. BTW: I don’t want to assume, so I’ll ask. But using ec.deleteObject(donor); it ‘appears’ that the ec also knows and deletes the one-to-many inserts it has pending for it as well. Is this true?
Thanks again!
on 5/3/06 14:42, David LeBer at [EMAIL PROTECTED] wrote:
> On 3-May-06, at 5:34 PM, WebObjects wrote:
>
>> I can't seem to get around java.lang.ClassCastException
>>
>> I know the EO's are of a known type, and using System.out.println
>> ("Here is entity name: " + myObjectToTest.entityName());
>>
>> ...but when I try to use "myObjectToTest.strLastName()" to access
>> the 'Last name string' (a known method of this entity) it doesn't
>> recognize it at compile time. When I cast the object to the entity
>> type (just for kicks) I get the cast exception.
>>
>> I'm a little stuck. The code is messy (work in progress syndrome),
>> but I've pasted it below. All help is always appreciated :)
>
> EOEnterpriseObject doesn't have a method strLastName().
>
> Investigate valueForKey instead.
>
> String lastName = (String)donor.valueForKey("strLastName");
>
>>
>> -Bill
>>
>> --- code segment ---
>>
>> NSArray tester = new NSArray(ec.insertedObjects());
>>
>> Enumeration enumerator = tester.objectEnumerator();
>> while (enumerator.hasMoreElements()) {
>> EOEnterpriseObject donor = (EOEnterpriseObject)
>> enumerator.nextElement();
>>
>> System.out.println("Here is entity name: " +
>> donor.entityName());
>> System.out.println("Here is Last Name: " +
>> donor.strLastName());
>>
>>
>> ec.deleteObject(donor);
>> }
>>
>>
>>
>>
>> on 5/3/06 14:01, Ken Anderson at [EMAIL PROTECTED] wrote:
>>
>>> Bill,
>>>
>>> Are you only interested in one kind of EO to possibly delete? Why
>>> not check the eo's entityName(), and if it's the one you want, cast
>>> it to the right type and just send the correct methods? IE:
>>>
>>> if (myObjectToTest.entityName().equals("Item")) {
>>> Item item = (Item) myObjectToTest;
>>>
>>> if (item.methodIWantTocheck() == null)
>>> ec.deleteObject(item);
>>> }
>>>
>>> Ken
>>>
>>> On May 3, 2006, at 4:55 PM, WebObjects wrote:
>>>
>>>> I'm taking a poke at using "ec.insertedObjects()" to evaluate each
>>>> object
>>>> prior to saving. So far I can grab an array of the objects,
>>>> although I had
>>>> to cast them into EO's and not simply their entity type (code
>>>> immediately
>>>> following):
>>>>
>>>> NSArray tester = new NSArray(ec.insertedObjects());
>>>>
>>>> Enumeration enumerator = tester.objectEnumerator();
>>>> while (enumerator.hasMoreElements()) {
>>>> EOEnterpriseObject myObjectToTest =
>>>> (EOEnterpriseObject)enumerator.nextElement();
>>>> ...}
>>>>
>>>> ...I'm pretty close, the next thing I'm doing is trying to gain
>>>> access to
>>>> the KeyValues within the EOEnterpriseObject, which I'm trying to
>>>> use the
>>>> following to get at this...
>>>>
>>>> NSArray allPropertyKeys()
>>>> Returns all of the receiver's property keys.
>>>> NSArray attributeKeys()
>>>> Returns the names of the receiver's attributes (not
>>>> relationship
>>>> properties).
>>>>
>>>> ...however, these only seem to return the Property keys and not the
>>>> properties/values. The API isn't the easiest to read. My goal is
>>>> to get at
>>>> the values and then to use ec.deleteObject( myObjectToTest ) when
>>>> needed.
>>>>
>>>> What is the right method to access the Keyvalues-properties?
>>>>
>>>> Thanks!
>>>>
>>>> -Bill
>>>>
>>>>
>>>> on 5/2/06 19:07, Ken Anderson at [EMAIL PROTECTED] wrote:
>>>>
>>>>> No, but doing ec.deleteObject(obj) will. If the object is new and
>>>>> has never been saved, it will effectively be nullified.
>>>>>
>>>>> On May 2, 2006, at 10:01 PM, WebObjects wrote:
>>>>>
>>>>>> Art,
>>>>>>
>>>>>> I'm thinking of EOEditingContext.insertedObjects() as the
>> choice in
>>>>>> this
>>>>>> case. I actually thought that may be the answer here (thanks for
>>>>>> your time
>>>>>> on this).
>>>>>>
>>>>>> If I were to remove an element of the NSArray returned by this
>>>>>> method, would
>>>>>> then calling .saveChanges() on the ec now exclude objects removed
>>>>>> from the
>>>>>> array? If so is this because of the magic of WO keeping track of
>>>>>> things?
>>>>>> (it seems to easy, like I'm missing something)
>>>>>>
>>>>>> Thanks for your wisdom,
>>>>>>
>>>>>> -Bill
>>>>>>
>>>>>>
>>>>>> on 5/2/06 18:53, Art Isbell at [EMAIL PROTECTED] wrote:
>>>>>>
>>>>>>> On May 2, 2006, at 2:48 PM, WebObjects wrote:
>>>>>>>
>>>>>>>> I've found an error in my coding style - too late in this
>> project
>>>>>>>> though. I
>>>>>>>> use EOUtilities.createAndInsertInstance in a constructor for a
>>>>>>>> page, and as
>>>>>>>> a result 'refresh' and 'back' have become my enemies.
>>>>>>>>
>>>>>>>> How can I iterated over the unsaved objects in an
>> EditingContext
>>>>>>>> (ec), test
>>>>>>>> their validity (ie. if ItemAt(0).getSomeValue() == null,
>> etc) and
>>>>>>>> delete
>>>>>>>> them from the ec prior to .saveChanges() ?
>>>>>>>
>>>>>>> It would seem that if you can modify your code to iterate over
>>>>>>> unsaved objects, that you could also modify your constructor
>> to fix
>>>>>>> this problem. But maybe not...
>>>>>>>
>>>>>>> EOEditingContext.insertedObjects() returns an array of inserted
>>>>>>> objects.
>>>>>>>
>>>>>>> Or probably better, assuming that you can modify your
>> constructor,
>>>>>>> would be to create a new editing context assigned to an instance
>>>>>>> variable of this component, lock it, and insert your new objects
>>>>>>> into
>>>>>>> this new editing context. Then if the user backtracks or
>>>>>>> refreshes,
>>>>>>> only objects inserted into the editing context of the current
>>>>>>> instance of this component would be saved. Objects inserted
>> into
>>>>>>> other instances of the same component would be freed when the
>>>>>>> component drops out of the page cache without being saved to the
>>>>>>> DB.
>>>>>>>
>>>>>>> Aloha,
>>>>>>> Art
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (Webobjects-
>> [EMAIL PROTECTED])
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/
>> webobjects%
>>>>>>> 40concyse.com
>>>>>>>
>>>>>>> This email sent to [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/lists%
>>>>>> 40anderhome.com
>>>>>>
>>>>>> This email sent to [EMAIL PROTECTED]
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list ([email protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/lists%
>>>> 40anderhome.com
>>>>
>>>> This email sent to [EMAIL PROTECTED]
>>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/dleber%
>> 40codeferous.com
>>
>> This email sent to [EMAIL PROTECTED]
>
>
> --
> ;david
>
> --
> David LeBer
> Codeferous Software
> 'co-defer-ous' adj. producing or containing code
> site: http://www.codeferous.com
> blog: http://david.codeferous.com
>
>
>
>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
|
