[Java] Inserimento dati in un DB

[Alex'87]

Hai aperto il link che ti ho fornito?
Ci sono degli esempi piuttosto chiari...

[Jamie04]

Hai aperto il link che ti ho fornito?
Ci sono degli esempi piuttosto chiari...

Sì sì ma non avevo capito molto bene, nel frattempo credo di aver risolto, almeno funziona:

    public static void insertMenu(String field) {
        try {
            if (field.isEmpty()) {
                JOptionPane.showMessageDialog(null, "Non puoi inserire un menu senza nome!", "Errore!", JOptionPane.WARNING_MESSAGE);
                return;
            }
            PreparedStatement pst=null;
            String query="INSERT INTO Menu VALUES (NULL, ?)";
            pst = connection.prepareStatement(query);
            pst.setString(1,field);
            int executeUpdate = pst.executeUpdate();
        } catch (SQLException e) {
            JOptionPane.showMessageDialog(null, "Si è verificato un problema\nnell'inserimento dei dati!", "Errore!", JOptionPane.WARNING_MESSAGE);
            Logger.getLogger(DBConnection.class.getName()).log(Level.SEVERE, null, e);
        }
    }

Che ne pensi di questo metodo?

Inoltre mi sono accorta che se cancello dei record e poi ne inserisco di nuovi l'ID (che ho definito con AUTO_INCREMENT) dei nuovi inseriti si incrementa di 1 ma partendo sempre dai valori che ho cancellato e non dagli ultimi rimasti. Come posso fare in modo che se cancello un record il prossimo che inserisco abbia l'id del record cancellato?

[Alex'87]

Che ne pensi di questo metodo?

E' un po' sporco e poco leggibile ma è corretto. Ah, non hai chiuso lo statement (in modo da liberare risorse)

Non mi piace la gestione delle eccezioni

Inoltre mi sono accorta che se cancello dei record e poi ne inserisco di nuovi l'ID (che ho definito con AUTO_INCREMENT) dei nuovi inseriti si incrementa di 1 ma partendo sempre dai valori che ho cancellato e non dagli ultimi rimasti. Come posso fare in modo che se cancello un record il prossimo che inserisco abbia l'id del record cancellato?

Allora togli AUTO_INCREMENT e gesti a mano l'incremento dell'ID. Ma detto francamente... ti turba avere dei "buchi" tra gli ID? L'id dovrebbe essere univoco... non ha senso riassegnare quelli di elementi cancellati...

[Jamie04]

E' un po' sporco e poco leggibile ma è corretto. Ah, non hai chiuso lo statement (in modo da liberare risorse)

"Sporco e poco leggibile", perché? Se ti va di spiegarmelo.
Perché non ti piace la gestione delle eccezioni?

Allora togli AUTO_INCREMENT e gesti a mano l'incremento dell'ID. Ma detto francamente... ti turba avere dei "buchi" tra gli ID? L'id dovrebbe essere univoco... non ha senso riassegnare quelli di elementi cancellati...

sì in effetti è un falso problema, mi era solo saltato all'occhio, credevo che un id liberato venisse riassegnato.

[Alex'87]

"Sporco e poco leggibile", perché? Se ti va di spiegarmelo.

- Il codice è tutto ammassato, non ci sono righe vuote che separano le varie operazioni. Ad esempio, hai codice di controllo e operazioni vere e proprie troppo amalgamate. Questo rende difficile capire a colpo d'occhio cosa stai facendo
- Usi variabili inutili, ad esempio per la query: passa direttamente al prepareStatement, no?

Sì, sono talebano su 'ste cose

Perché non ti piace la gestione delle eccezioni?

Non c'è il finally: in caso di eccezione lo statement resta aperto, andando a occupare inutilmente risorse.

Il problema più grave IMHO è che in caso di eccezione stai facendo <i>troppo</i>: insertMenu dovrebbe fare una query, e basta. Te gli stai dando la responsabilità di avvisare l'utente che qualcosa è andato storto. Questa gestione andarebbe fatta a livello più alto: cosa succede se insertMenu facesse parte di una libreria che distribuisci ad altri sviluppatori? Potrebbe essere usata in un contesto in cui l'interfaccia grafica neanche esiste (pensa ad un batch notturno che legge dei dati da file e inserisce tutto a db, senza l'intervento dell'operatore). insertMenu() dovrebbe limitarsi a lanciare l'eccezione: sarà chi lo chiama a decidere cosa fare: avverto l'utente? Scrivo in un file di log? Mando una email al responsabile?

Spero di essere stato chiaro ^^


Io avrei fatto una cosa del genere, delegando la gestione a chi chiama il metodo:

    public static void insertMenu(String field) throws SQLException, IllegalArgumentException {
        PreparedStatement statement = null;

        try {
            if (field == null || field.isEmpty()) {
                throw new IllegalArgumentException("Please provide a not-null and not-empty value for 'field'");
            }

            statement = connection.prepareStatement("INSERT INTO Menu VALUES (NULL, ?)");
            statement.setString(1, field);
            statement.executeUpdate();
        } finally {
            if (statement != null) {
                statement.close();
            }
        }
    }

sì in effetti è un falso problema, mi era solo saltato all'occhio, credevo che un id liberato venisse riassegnato.

Sarebbe un problema se venisse riassegnato visto che in genere un auto_increment è usato (purtroppo) come primary key...



Ah, anche il fatto che sia static non mi piace ma bisognerebbe vedere un attimo come hai organizzato l'architettura dell'applicazione.

[schumy2000]

Sarebbe un problema se venisse riassegnato visto che in genere un auto_increment è usato (purtroppo) come primary key...

Non capisco perché purtroppo...so bene che ogni tanto viene abusato...ma altre volte (la maggior parte IMHO) è un dato che ti "salva"

[Jamie04]

- Il codice è tutto ammassato, non ci sono righe vuote che separano le varie operazioni. Ad esempio, hai codice di controllo e operazioni vere e proprie troppo amalgamate. Questo rende difficile capire a colpo d'occhio cosa stai facendo
- Usi variabili inutili, ad esempio per la query: passa direttamente al prepareStatement, no?

Ok, ho messo un po' di spazi e di commenti in più e tolto la stringa inutile

Non c'è il finally: in caso di eccezione lo statement resta aperto, andando a occupare inutilmente risorse.
Il problema più grave IMHO è che in caso di eccezione stai facendo <i>troppo</i>: insertMenu dovrebbe fare una query, e basta. Te gli stai dando la responsabilità di avvisare l'utente che qualcosa è andato storto. Questa gestione andarebbe fatta a livello più alto: cosa succede se insertMenu facesse parte di una libreria che distribuisci ad altri sviluppatori? Potrebbe essere usata in un contesto in cui l'interfaccia grafica neanche esiste (pensa ad un batch notturno che legge dei dati da file e inserisce tutto a db, senza l'intervento dell'operatore).

Ok, però questo è solo un progetto per un esame, non è un vero software che dovrò distribuire a qualcuno. Non è previsto che debba funzionare senza interfaccia grafica perciò non mi sono preoccupata di questi dettagli. Le tue critiche mi sembrano più che sensate ma credo che nel contesto in cui sono attualmente posso evitarmi queste complicazioni. Del resto nel corso che abbiamo fatto nessuno ci ha spiegato veramente come mettere in piedi un'applicazione complessa.
Ammetto che la gestione delle eccezioni è ancora un po' oscura per me, infatti mi limito a prendere spunto da esempi già fatti. Ho capito il concetto a grandi linee ma non conosco tutte le sottigliezze.

Sarebbe un problema se venisse riassegnato visto che in genere un auto_increment è usato (purtroppo) come primary key...

perché purtroppo?

Ah, anche il fatto che sia static non mi piace ma bisognerebbe vedere un attimo come hai organizzato l'architettura dell'applicazione.

perché non dovrebbe essere static? sinceramente su questa cosa non ci ho riflettuto molto mi sono limitata a modificare la classe che ci aveva fornito il prof a suo tempo per connettersi a un database e i metodi erano tutti statici, così gli altri che ho inserito (inserimento dati e creazione db e tabelle) li ho fatti uguale...

grazie per i tuoi consigli!