in practice would you literally have an arraylist of Pages or an arraylist of pageIDs?

(similar to my category question I posted on the site -- if it makes sense to hold nested objects or nested ids)

Random guess--The Godfather?

lolnope

Oh, rock band?

And no, I've not watched the Godfather.

neither did I.

@Hosch250 probably more known by them is "Self Esteem"

Yeah, I can't stand rock.

Consequently, I only know the major bands.

To be Fair, that's more Punk than Rock

And some jokes about them, like the time the falcon (F16, maybe?) flew over a concert and killed two Stones with one bird.

usually you try to not involve the DB too much: so you'll have a list of Pages (and not Ids)

@Vogel612 To this day my favorite song by The Offspring

overall their music isn't terribly interesting though...

Much of it is pretty bland

Older stuff is better, the album this one was on (Americana) is probably their last album that was mostly Punk

They got quite mainstream afterwards

BTW, what's the difference between punk and ordinary rock? I usually hear about "punk rock", "rock", "heavy metal", etc.

Like, what's the big difference? They all sound more/less the same to me.

so if you were using an ORM, then each object would basically have its ID somewhere (abstracted away in some collection somewhere, linked to each object)

Those 3 have very different roots

how would the above change with an ORM, basically?

Punk rock is usually quite fast, fairly simple, often with provocative/political lyrics

Like the two guys who came up with calc at different times from different roots? :P

punk is simple: it has 3 chords and it's rooted in left-wing anti-authoritarian "antifascist" movements

Also that^

I assume you guys have heard of the 4-chord song

Oh yeah

Rock is something like the spiritual successor to blues, but it's. ... different

By "3-chord" and "4-chord" do you mean 3/4 and 4/4 beat songs?

and heavy metal is just a spin-off with more distortion in guitars and darker lyrics

@Hosch250 no that's the beat. Are you not familiar with the concept of chords?

@Hosch250 No, that's time signature

Not really--I played the clarinet.

Hard to do chords on that instrument ;)

and thrash metal is... well, take Metallica's Fight Fire With Fire to get an idea. Then there's melodic metal, like In Flames' Dialogue With The Stars... metal is so colorful

hmm... A chord is (usually at least three) distinct tones played at the same time in certain intervals (namely a small and a large third)

A lot of punk song use mostly I - IV - V chords

chords are basically just notes that sound good together

but there is mathematical basis behind it

Yeah, I played piano some.

Well, they don't HAVE to sound good :)

:P

@The29thSaltshaker Primus makes good use of dissonant chords ;-)

I know the basic chords of the scale, but not a lot about them.

Take Moonlight Sonata third movement for example

looks crazy complex (and it is) but it's just chord progression

Yep

well 3/4-chord songs use just ... only 3 (or 4) distinct chords in the whole song

Didn't get that far ;)

Oh, OK.

@Vogel612 Ya coulda told me that without all the fuss ;)

@The29thSaltshaker Like how Coltrane's solo on Giant Steps is basically arpeggios :P

@SirPython Like the fish in Carnival of the Animals.

hahaha

Bah, not as fun on guitar ;P

^^ pure awesomeness

Cziffra was baller

Welcome to The 2nd Monitor Music Appreciation!

I like folk/county style. Although, some country is off-limits for naughty lyrics.

ooh music I have loads of great dubstep, sec

And dance. I have a whole collection (two long CD's worth) of Strauss.

Just in case anyone hasn't seen it yet: youtube.com/watch?v=5pidokakU4I

@arda dubstep ಠ_ಠ

or youtube.com/watch?v=JdxkVQy7QLM

@Phrancis seriously? the technical prowess in that video is just mind-blowing

haven't seen that guitar video before

that's insane

@Mat'sMug I'll give it a listen, doubt it's as "pretty" as the piano one though :)

It would be better on a "normal" guitar.

Oh wow, that doesn't even sound like a guitar :(

@Phrancis dubstep is great when you just want something distractive

youtube.com/watch?v=jKwyQXR7mQI >.>

lol

@The29thSaltshaker there's ... "worse"?

Moonlight Sonata I & III reminds me of playing EWJ2 on Super Nintendo :D

here you go. 1683 songs, 118 hours of dubstep. open.spotify.com/user/ardaozkal/playlist/1Qfx9nv2qzysv4BHPftGyt

the race against psycrow?

most are old, but doesn't matter if you are new to edm

@The29thSaltshaker Yeah I think so. And first movement were in those swimming levels

i can't remember which stage used the first movement

ahhh that's right

@Phrancis /me too young ... what's EWJ2?

great now i have that song from hell stuck in my head

i always forget the real name of it

Earthworm Jim @Vogel612 ;-)

@Vogel612 earthworld jim 2

@Vogel612 Earthworm Jim 2

dunnnnn, dunnn, dun dun dun dunnnnnn, dun dunnnnnnnnn

Groovy!

lol

It always bugged me that the EWJ2 roms were buggy as hell regardless of emulator

But the swimming level with Moonlight Sonata was in the original EWJ. Unless they did it again in EWJ2, but I don't recall playing the second game

Nothing like the old cartridge, need to find a copy of that

@Mat'sMug Wrong, that was definitely EWJ2

it was that level with the intestines/cilia i think?

The hamster, right?

Was another level similar called The Villi People later in the game also

Or whatever lol

In the first game it was all blue-ish shades, and glass... gosh that's faaaaaaar in the dusty back of my old brain

@Mat'sMug Yep, remember the level too, but it had different music

Maybe I'm mixing things up

Anyway, TTFN

← 106 messages moved from The 2nd Monitor

@Phrancis :(

I would expect all the DML to be already included in the DB that ships with the app, or at worst, for it to be ran only if the app is started and those tables don't already exist

@Phrancis The create-table query only runs once when the database is instantiated for the first time

in Android the onCreate() statement only gets called once, and then it never gets called again unless you increase the version number

Or maybe that's wrong actually

might just call onUpgrade instead

That's a strange place to put it inside a Book class, I'd imagine more of a DatabaseSetup class or something (along with all the other DB objects' DML create statements)

just the query itself?

a dedicated query class?

The way you have it would be analogous to a book that can create its own bookshelf

I don't understand

I am just trying to determine what the most logical place is to store those particular components

I've only defined a Book, not a Bookshelf

A book doesn't have a book shelf (i.e. a BOOKS table), rather, the bookshelf has 0 or more books

oh i see what you mean

but does it generally make sense to put the table field names in the POJO?

or does all that stuff get separated out into their own classes/layers?

(the reason why I had put them in Book is so that I could do Book.someColumnName)

If the object uses the fields, then yes, it makes sense, I would think

so you would go with the second example in the post?

keep the field names in the POJO, move the create-table query out?

The create-table is not a good example (for reasons already mentioned) no matter where you put it. I would imagine something like a BookQueries class that has methods called from the Book class, to do something with the fields, like inserting, updating, selecting...

how would the table get created without a create-table statement?

It needs the create-table statement, of course, but the table (or bookshelf) is never a property of the book

right

I guess what I am asking is where would you put those pieces? the column names, the table name, the create-table query, etc

right

Hence, a DatabaseSetup class or procedure of some kind, independent of Book or any other such classes

would you put the book fields in there too? table name, id column name, title column name, etc

or keep those in Book?

@The29thSaltshaker I'd put those only where your create-table statement is

Your Book class/object should only be concerned about itself, i.e., the fields that can be related to a book

@Phrancis So something like this?

...
    @Override
    public synchronized void onCreate(SQLiteDatabase db) {
        DatabaseSetup.createTables(db);
    }
...

@Phrancis And then

public class DatabaseSetup {

    //table names, fields, etc

    public static final String BOOK_TABLE_NAME = "BOOK";
    public static final String BOOK_COLUMN_ID = "ID";
    public static final String BOOK_COLUMN_TITLE = "TITLE";

    //create-table queries

    public static final String CREATE_TABLE_BOOK_STRING =
            "CREATE TABLE " + BOOK_TABLE_NAME + " ("
                    + BOOK_COLUMN_ID + " INTEGER PRIMARY KEY AUTOINCREMENT, "
                    + BOOK_COLUMN_TITLE + " TEXT NOT NULL)";

Kinda, except, if all you are doing is create the tables there, you don't need those variables, just write out the query as a complete string and then execute it

for CRUD operations later I would need the variables, no?

e.g. select all from BOOK_TABLE_NAME where BOOK_COLUMN_ID = some passed-in parameter

Yeah, but you'd have those in their respective classes/objects, not in the setup class

that's what I have been asking about though :(

ok, will try this again:

Hold on let me draft some example code real quick to illusrate

public class DatabaseSetup {

    //create-table queries

    public static final String CREATE_TABLE_BOOK_STRING =
            "CREATE TABLE " + Book.TABLE_NAME + " ("
                    + Book.COLUMN_ID + " INTEGER PRIMARY KEY AUTOINCREMENT, "
                    + Book.COLUMN_TITLE + " TEXT NOT NULL)";

    //function that calls any/all setup queries

    public static void createTables(SQLiteDatabase db) {
        db.execSQL(CREATE_TABLE_BOOK_STRING);
    }
}

public class Book {

    public static final String TABLE_NAME = "BOOK";
    public static final String COLUMN_ID = "ID";
    public static final String COLUMN_TITLE = "TITLE";

    private String title;
    private final List<Page> pageList = new ArrayList<>();

    public Book(String title, List<Page> pageList) {
        this.title = title;
        this.pageList.addAll(pageList);
    }
   //...

OK @The29thSaltshaker look at this

public class DatabaseSetup {
    public static final String CREATE_TABLE_BOOK =
    "CREATE TABLE BOOK ("
    + "ID INTEGER PRIMARY KEY AUTOINCREMENT, "
    + "TITLE TEXT NOT NULL,"
    + "ISBN TEXT NULL,"
    + "YEAR INTEGER NULL)";
    // other create statement strings as needed

    public static void createTables(SQLiteDatabase db) {
        db.execSQL(CREATE_TABLE_BOOK);
        // exec other create statements
    }
}

// elsewhere in the app
public class Book {
	private int id;
	private String title;

but then when you do CRUD later you'll have to use the same column names again

Your Book class shouldn't care what the fields are called in the DB, only what values the book has

for example let's say you are going to do insertBookIntoDatabase

you'd need to use the fields

If you're doing your own CRUD, yes, you do, but there's not really any sense in having those in Book class, something like BookDbHandling or BookQueries class called from that method

Separation of concerns, think of the queries like the librarian, so-to-speak; the book doesn't need to know how to place itself on the bookshelf, or how to pick itself up from it; that's the librarian's (or helper class) job

In that sense, the ORM would be like a librarian that already knows how to do all of its tasks, versus if you write your own CRUD then you need to teach your librarian all of its separate tasks

So then could it be argued that the getFields, updateBook, insertBook, etc methods should be in their own class as well and not part of Book? or no?

Um, yes, that's probably a good way to look at it, in fact; makes a lot of sense

or perhaps all of that stuff into the bookQueries class?

create-table statements, insert statements, select, delete, etc

Not create-table statements

anything involving the nexus between books and databases

The other ones, sure, you could design it that way

hm i guess it makes sense, as create-tables are more of a ... setup/one time deal

no real need to clutter things up

You could also do something like Book <-> BookHandler <-> BookSqlQueries

what's the difference between the latter two?

if handlers naturally require queries

What action to do with the Book, vs. How to do the action

I don't quite understand the difference

So the create-table statement would be in BookSqlQueries, right? Or is that always going to be ideally in some DatabaseSetup thing with all the other create-table queries

The Handler wouldn't even need to know that a DB exists, for all it knows it could be written to an XML or JSON file, or even nothing done with it

@The29thSaltshaker create-anything statements should be in setup, since that's what they are

what would an insert function look like as a handler?

just passing along Book.tablename, Book.getId(), Book.getTitle(), Book.getISBN(), etc?

//BookHandler
private boolean addNewBook(Book thisBook) {
    boolean success;
    String title = thisBook.getTitle();
    String isbn = thisBook.getIsbn();
    Integer year = thisBook.getYear();
    BookSqlQueries.insertBook(title, isbn, year);
    //wait for response to confirm...
    return success;
}

Something like that^ perhaps

1 sec

← 76 messages moved from The 2nd Monitor

OK better continue here @The29thSaltshaker

ok

Now, if you prefer, you can do your queries in a Handler/Helper class itself, that may be simpler. But I would keep them out of Book class in all cases

So basically we'd have a PageHandler, PageQueries, BookHandler, BookQueries, etc

DatabaseSetup that handles all the create-tables

field names inside the objects

(or perhaps inside the handlers)

Do you think a book should have a getPages() method? I think a book should at least have access to its pages

sure

but you could have a page handler class too, which has the different ways/things to do with pages

but would getPages() be more of a handler method or a getter for a list of Pages or something simialr

i.e. access the DB if you want the pages, eager-store the pages on load, or don't load them, etc

I think it would make sense for a book to be able to access its own pages, but the book shouldn't really care how the pages are accessed/stored, etc.

i agree

private Pages getPages() {
    return PageHelper.getPages(bookId);
}

You get the idea I'm sure

is this different from PageHandler?

Handler/Helper, same difference lol :)

just checking XD

but this also assumes that every time we get the pages we query the db, yes?

i guess this depends on expected use case?

if we're going to be getting the pages a lot vs. .... not

Yeah. The PageHelper should handle that part, whatever method you choose

I'd personally only get the pages data from DB once it is called for, to save memory (though at a bit of a cost in time spent accessing them)

because odds are we aren't going to be popping in and out of books like crazy

From a presentation/application standpoint, you could imagine maybe a "Book List/Search" functionality, then choosing a book to see Book Details, then choosing to see the Book Pages

You could load the pages eagerly at the Book Details portion, in expectation of potentially having to access them, or only get the pages once Book Pages is selected

I would certainly not get the pages at the Book List/Search though

would you get them during details (because people might be spending time reading those details anyway) or when actually requested?

Depends. First one would be quicker to view the pages, if that option is selected (at the expense of using some memory that may or may not be accessed), or wait until it is actually requested, in which case it would take a bit longer (waiting for the DB to return data), but the memory would not be taken if the user does not wish to see the pages

If you were really really tight on memory, you could even just load a few pages as needed (though that would be more work to program it)

right

the old playstation level-loading strategy XD

Urgh, yes lol.

Hopefully all this talk today has given you some ideas and things to think about in designing App <-> DB

So if I were using an ORM, the Query classes would basically get fried

Pretty much, yeah

handler class might be kept though

I've never used an ORM myself so don't take anything I say about it for granted

thanks for answering all my questions -- it's been really helpful

I would say yes, the handler would still be kept, to maintain the separation of concerns. The handler would just be a whole lot simpler

(the reason I'd keep it is that it can be updated easily between frameworks if need be)

Yep

Zak vs. Mast: 1036 diff. Year: +1963. Quarter: +128. Month: +818. Week: +60. Day: 0.

syb0rg vs. Vogel612: 260 diff. Year: -51. Quarter: +284. Month: +284. Week: -15. Day: +5.