EJB - Update / Delete

opdater:

home findByPrimaryKey
bean setXxxx

slet:

home remove

og du skal slet ikke bekymre dig om noget implementations kode - den genererede
kode ordner det hele

tak for svaret, det virkede fint med update men remove kom den stadig med fejl ved

Den sagde at den ikke kunne sætte primary key til null
hvilket jo heller ikke er meningen den skal.

nu skal vi bare finde ud af hvordan man fra en anden container tilgår vores container og har mulighed for at lave kald i vores session interface

har I implementeret noget i bean klassen for remove ?

hvis jeres session bean har et remote interface så er det kun et spørgsmål om
at få JNDI lookup til at virke

samme app-server => piece of cake

anden app-server => kan godt drille lidt

altså:

samme = 2 x JBoss eller 2 x WebLogic

anden = JBoss og WebLogic eller JBoss og WebSphere

fejlen den kommer med er:
Transaction was rolled back: javax.ejb.EJBException: Error saving state: ORA-01407: kan ikke opdatere ("ANDRAS17"."SCORE123"."BRUGERID") til NULL

fra clienten ser kaldet sådan ud:
sessionEJB.removeScore(new Long(16));

fra session beanen ser kaldet sådan ud:

public String removeScore(Long id)
  {
    try
    {
      Score123Local removeScore = getScore123LocalHome().findByPrimaryKey(id);
      removeScore.remove();
   
    }
    catch (RemoveException e)
    {
      System.out.println("bla bla");
    }
    catch (FinderException e)
    {
      System.out.println("uga uga");
    }
    catch (NamingException e)
    {
      System.out.println("joh john");
    }

det var jo ikke det jeg foreslog ...

prøv:

getScore123LocalHome().remove(id);

misforstod det lidt men det hjalp desvære ikke så meget :(

public String removeScore(Long id)
  {
    try
    {
      getScore123LocalHome().remove(id);
   
    }
    catch (RemoveException e)
    {
      System.out.println("bla bla");
      System.err.println(e);
    }
   
    catch (NamingException e)
    {
      System.out.println("joh john");
    }
   
    return null;
  }

consolen:
05/11/02 11:56:11 bla bla

05/11/02 11:56:11 javax.ejb.RemoveException: Exception due to: javax.ejb.EJBException: Error saving state: ORA-01407: kan ikke opdatere ("ANDRAS17"."SCORE123"."BRUGERID") til NULL
:Error saving state: ORA-01407: kan ikke opdatere ("ANDRAS17"."SCORE123"."BRUGERID") til NULL

så det er stadig det samme den klager over.

og I har ikke noget i ejbRemove ?

nej dne er tom.

public void ejbRemove()
  {
  }

så vidt vi forstod lå det i container managed at man ikke selv skulle ændre / lave disse.

det er også rigtigt - jeg var bekymret for om i lavede noget

er der nogen foreign key constraints ?

ja brugerid er en forign key til en tabel der heder bruger osm har en værdi wsom heder id

men i dette tilfælde burde id være parrent og idbruger være child og childed skulle nedlægges før parrent kan nedlægges.

så derfor bør score nedlæges før brugeren.

smider lige sql koden ind:

bemærk det er prototyping vi er igang med så dubehøver ikke nævne at database tabellerne godt kunne ligge i en tabel :-)

drop table bruger123 cascade constraints;
create table bruger123 (
  id        number(4) not null primary key,
  navn          varchar2(50) not null );
 
drop table score123 cascade constraints;
create table score123 (
  brugerid      number(4) not null references bruger123 primary key,
  sejre        number(5),
  nederlag      number(5));

men pga den parrent/child fordelling "burde" det som vi ser det ikke give noget problem men kan da godt være det er der fejlen ligger

jeg kan sagtens følge din logik

http://www.caucho.com/support/ejb-interest/0303/0056.html
http://sourceforge.net/mailarchive/forum.php?forum_id=2266&style=flat&viewday=2&viewmonth=200308

taler også om relationer

igen ville jeg lige skrive takfor hjælpen, den delete er ikke så vigtig igen i vores projekt men man bliver jo stædig når tingene ikke vil som man selv vil uanset om det er af minimal vigtighed :)

men vi fandt ikke helt ud af det vi fik leget lidt med at oprette nogle andre tabeller uden at lave nolge relationer overhovdet og detvirkede fint så det må næsten være relationerne som er årsag til det, og vi fik også fundet et menu vidue hvor vi kunne ændre på om det skulle være cascade eller hvordan constraintsne skulle håndteres, vi fik dog ikke nået at afprøve det så det må blive i morgen.

jeg ligger et svar imens

NB: det er iøvrigt sjældent at man deleter noget - som regel vil man bare markere det
    som inaktivt eller lignende