Database programming

G'day /prog/

I'm writing a java application with a mysql db backend (indeed, performance is not what I'm after), but I'm struggling a bit. How does one go about saving data? Do you execute an update query whenever a class representing a table is changed, or would there be an interval? Or am I going about this entirely wrong?
Your advice will be greatly appreciated.

D:

i'd save the changed values in localhosts memory, once confirmed then update. or get drunk and get some bitches and hoes

>>3
That sounds like the most logical thing to do. Is there any point at all in updating first, then checking whether the query executed successfully and only then update the class?

>>4

instead of querying for success, have some algorithm check the data locally. quering before submit can be used for unique data

You are now listening to I am a database manually.

♪I am a database and that is all I'll ever be ♫ I am a database free from redundancy ♬

>>7
lol'd

>>5
By successful query execution, I meant a lack of thrown exceptions, not so much querying for success. But yeah, I get your point. Thanks.

I've read some websites about persistence. Is this the way to go or am I on the wrong track? Could anyone perhaps point me at some useful tutorials?

>>7
you sir won one internet for this epic shit.

For future reference, http://www.last.fm/music/Makke/_/I+Am+a+Database

>>10
What the fuck is wrong with you?

>>1
Consider some of the most truly ENTERPRISE SOLUTIONS known to man: Hibernate and Java ENTERPRISE Beans, designed to solve those very problems.

>>13

Hibernate looks to be exactly the thing I need. Thank you :)

>>14
Enjoy wasting three hours collecting various libraries and dependencies for Hibernate. Oh, and enjoy spending a few more hours on setting up the config file. You could've probably solved any problem in that time using java.sql and friends.

>>15
Everything that teaches me new stuff isn't a "waste of time".
So yes, I will enjoy it, thank you.

>>10
Oh lord have I ever BT.

JPA (TopLink/Hibernate implementations) is truly a pain in the ass. Enjoy trying to migrate from one persistence unit to a new one... because there's no formal way to do this. Persistence is nice in languages like ruby, but in Java it can be a real pain in the ass. The ONLY reason I see to use a persistence layer is if you want to do some continuous query web 3.0 shit. In the real Enterprise, you normally pick a dbms and stick with it, so it should really not be a matter of staying db agnostic.

Just pick a solid dbms (not MySQL... try postgresql) and go with that. The most you should consider is mapping SQL result sets to POJOs.

>>16
Hello, >>13 here.

>>15 is actually spot on. I joked about it being a solution due to its truly epic ENTERPRISE nature--layers upon layers upon layers of abstraction, dependencies, and quirky undocumented limitations. There's a reason they offer paid support for it--because you usually really fucking need it. It's best environment is for massive databases that deal with serious mission critical tasks. If you just have a few tables to mess around with, pretty much anything is a better solution.

But if as you say, you just want to learn, then Hibernate can be a powerful tool under your belt. Most are driven insane before it is ever really mastered.

>>18,19
Right. I guess e-sarcasm doesn't really work on me, eh. I'm determined to learn at least somewhat about Hibernate (you say most are driven insane by it - sounds like a challenge to me).
But I suppose you're right, and I shouldn't actually use it. My application is indeed too small for this sort of stuff, as I understand it.

So, how do I get rid of needing to write all this low-level query stuff for my classes? Well, I have written a code generator for this already anyway, but that's not quite what I'm trying to get at. I simply don't want this low-level stuff in my code *at all*, generated or not.

What do you suggest I do? I have no idea where to even start..

>>20
Look, you either have this horrible ``low-level'' stuff you seem to be so afraid of, or you use some sort of framework for abstracting database connections. However, most of these will suck as soon as you bring in some joins and other more complicated relations. Performance will go down if your data starts to exceed a certain amount of rows unless you write your queries yourself.

>>21
I'm not 'afraid' to write queries myself, it's just that it tends to make a huge mess of the code. Really all I'm asking is some advice as to how I should read/write from/to the database without making my code look like a terrible mess.

>>22

At work, I work with .Net on DB2.

Our convention is to place all queries in a separate XML file. This allows you to get to them in (mostly) one place and lets us pass it off to other people so that they can rewrite or add new queries. We just load queries from the file using a utility class and execute them as needed.

A generic driver interface is fine (Java's JDBC, or .Net's OleDb/ODBC). Find a connection pooling class or write your own.

This is also related to the "should a noobie start with vim/javac or NetBeans Enterprise Deluxe Edition first?"  You need to learn SQL anyway. Otherwise, JPA will only confuse the hell out of you. Not to mention, you are a shitty programmer if you can only use ORM frameworks for databasing.

>>23
How do you keep track of which query is stored where, and what they are for, etc? Doesn't it become a huge maze after a while? In my job we have literally thousands of views and stored procedures (and still most of the queries are hard-coded in the software - at least for the older applications), and although we applied some form of naming conventions, it has become really confusing after all this time.

My application currently does have a connection pooling class, and the classes representing table data are generated by a tool I wrote. It all works fine as it is, but I was hoping to find a more elegant way of doing it. I like what I've seen of Hibernate so far, but >>19 put me off it. I'm not necessarily looking for an ORM solution though. Just wanted to get some thoughts from others :)

>>24
Dude, if Hibernate looks interesting, give it a try. What's the worst that could happen?

>>25
Being embroiled in a world where XML is king?
A world where creative programming is shunned for "standards" that no one man can understand?
A world where there is no procedural, only object oriented?
A world where code cannot be specialised or fun, only generic?
A world where systems cannot be simple, beautiful or self explaining, only UML?
And finally /prog/...soulful.
Where you can feel the soul of the programmer coming through his code?

Oh yeah OP and >>25 ORMs are probobly overkill for this purpose, renember simple and well thought out programs are best.

<