| Time |
S |
Nick |
Message |
| 01:16 |
|
|
firebird1 joined ##javaee |
| 02:42 |
|
|
MasterProgram joined ##javaee |
| 03:15 |
|
|
cem__ joined ##javaee |
| 03:22 |
|
cem__ |
hello World! |
| 03:22 |
|
cem__ |
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines |
| 05:15 |
|
|
AndroidLoverInSF joined ##javaee |
| 05:39 |
|
|
kobain joined ##javaee |
| 07:32 |
|
|
AlexCzar joined ##javaee |
| 08:13 |
|
|
neuro_sys joined ##javaee |
| 08:38 |
|
|
AlexCzar joined ##javaee |
| 09:01 |
|
|
kotten joined ##javaee |
| 11:09 |
|
neuro_sys |
https://medium.com/on-coding/db854689243 |
| 11:19 |
|
pdurbin |
heh. "The Evolution of a Software Engineer". yeah, saw that the other day. good stuff |
| 11:41 |
|
|
fabioportieri joined ##javaee |
| 11:41 |
|
fabioportieri |
morning |
| 11:42 |
|
CJ_ |
Has anyone seen this? http://developers.slashdot.org/story/14/03/19/1934244/google-android-studio-vs-eclipse-which-fits-your-needs |
| 11:57 |
|
|
aspire joined ##javaee |
| 12:04 |
|
fabioportieri |
fucking mothafucka websphere |
| 12:22 |
|
cem__ |
:D |
| 12:23 |
|
cem__ |
fabioportieri: its the first seen you sooo evil |
| 12:23 |
|
cem__ |
fabioportieri: its the first time seen you sooo evil |
| 12:28 |
|
cem__ |
k my friend does like this , he saves the labels and elements in db and the page is completely dyna |
| 12:28 |
|
fabioportieri |
even gandhi would be raging in my shoes |
| 12:29 |
|
cem__ |
:D |
| 12:29 |
|
cem__ |
sooo evil! |
| 12:30 |
|
|
rwb joined ##javaee |
| 12:32 |
|
cem__ |
comparing 7zip with jar :/ |
| 12:32 |
|
cem__ |
woohoo 7zip |
| 12:32 |
|
cem__ |
jar wth! |
| 12:33 |
|
cem__ |
sfisque: how to set name for war file generated using pom.xml |
| 12:36 |
|
cem__ |
k leaving! |
| 12:36 |
|
cem__ |
:/ weird technology <NOOB> |
| 12:36 |
|
CJ_ |
O.o |
| 13:03 |
|
|
Naros joined ##javaee |
| 14:02 |
|
|
sajjadg joined ##javaee |
| 14:11 |
|
pdurbin |
what's the best way to communicate things to your team such as: 1. run this SQL script after you pull the latest code. 2. drop this new schema.xml file into place after you pull the latest code. 3. drop your database and create a fresh database after pulling the latest code. ? |
| 14:15 |
|
sajjadg |
1. you can use database migration framework like flywaydb (http://flywaydb.org/) |
| 14:16 |
|
sajjadg |
2. most people use scripts and tell their teammates to run them somehow with some rules (timestamp, or maybe they have a script that manages the updates) |
| 14:17 |
|
sajjadg |
I like the first method. it's a little tricky at first. but will help and ease the development in the long run |
| 14:25 |
|
pdurbin |
what it your project is open source and in theory the whole world is pulling the latest code and needs to know when to run these various updates to their dev environment? seems like there should be a central place to communicate this |
| 14:25 |
|
pdurbin |
s/what it/what if/ |
| 14:25 |
|
sajjadg |
what about the first method? |
| 14:26 |
|
|
AndroidLoverInSF joined ##javaee |
| 14:26 |
|
pdurbin |
sajjadg: that doesn't cover when people need to update non database things such as needing a new Solr schema.xml |
| 14:28 |
|
sajjadg |
I don't know. I probably don't understand the problem then. the way flywaydb works is to change the db with a native SQL script. |
| 14:30 |
|
sajjadg |
and JPA may have things to help :-/ (db creation and manipulation) |
| 14:37 |
|
pdurbin |
nobody has this problem? c'mon :) |
| 14:38 |
|
CJ_ |
pdurbin, I just go yell at people when they complain things don't work. |
| 14:39 |
|
pdurbin |
oh there is plenty of yelling, believe me :) |
| 14:39 |
|
sajjadg |
pdurbin, custom scripts. the only thing I've seen/heard. |
| 14:41 |
|
pdurbin |
maybe a file in source control called breaking-changes-to-your-dev-environment.txt? with dates in reverse order? |
| 14:45 |
|
pdurbin |
the idea is to have a single place to check |
| 14:46 |
|
sfisque |
pdurbin - that's a process question. either it's dictated by the tech lead and communicated down, or it's by committee. choose your poison |
| 14:47 |
|
pdurbin |
sfisque: I agree. what's your process? |
| 14:49 |
|
sfisque |
depends on the platform and the sophistication of the deployment agents (people/environment/etc.) in some cases, it's simply a txt file that says, "do this, then do this, then do that…". in other cases it's an ant script with custom plugins. in other cases, it's shell scripts. in one case it was a module in the product that would execute "migration steps" upon detecting a particular "state" (aka, i'm out of date, i have t |
| 14:52 |
|
sfisque |
i generally weigh: how much time can i devote to solving this problem, how much pain is it to help people through the problem, and how critical is failure/success in the deployment phase |
| 14:55 |
|
|
drspockbr joined ##javaee |
| 14:58 |
|
pdurbin |
well, dev grinds to a halt. people need to update their dev environments after they pull the latest code |
| 15:13 |
|
pdurbin |
we're experimenting with a folder in Google Drive. made a breaking change? create a doc. everyone has applied the fix locally? delete the doc |
| 15:20 |
|
|
firebird1 joined ##javaee |
| 17:48 |
|
|
AlexCzar joined ##javaee |
| 17:49 |
|
|
AndroidLoverInSF joined ##javaee |
| 17:56 |
|
|
AndroidLoverInSF joined ##javaee |
| 18:00 |
|
|
AndroidLoverInSF joined ##javaee |
| 18:17 |
|
|
AndroidLoverInSF joined ##javaee |
| 18:28 |
|
|
neuro_sys joined ##javaee |
| 18:28 |
|
|
neuro_sys joined ##javaee |
| 18:35 |
|
|
neuro_sy1 joined ##javaee |
| 18:47 |
|
|
jmb_ joined ##javaee |
| 19:18 |
|
pdurbin |
getting a little more chatter about this here: http://irclog.perlgeek.de/crimsonfu/2014-03-20#i_8466214 |
| 19:33 |
|
|
aspire_ joined ##javaee |
| 19:56 |
|
|
aspire_ joined ##javaee |
| 20:58 |
|
whartung |
well there's all sorts of solutions to that |
| 21:04 |
|
|
AndroidLoverInSF joined ##javaee |
| 21:07 |
|
|
kobain joined ##javaee |
| 21:19 |
|
|
AndroidLoverInSF joined ##javaee |
| 21:35 |
|
|
aspire joined ##javaee |
| 21:39 |
|
|
pdurbin_m joined ##javaee |
| 21:39 |
|
pdurbin_m |
whartung: do tell |
| 21:40 |
|
whartung |
what aspect are we talking about? |
| 21:41 |
|
pdurbin_m |
communication |
| 21:41 |
|
pdurbin_m |
of breaking changes |
| 21:42 |
|
pdurbin_m |
within a dev team |
| 21:43 |
|
|
AndroidLoverInSF joined ##javaee |
| 21:43 |
|
pdurbin_m |
so people can fix their broken dev environment after a git pull |
| 21:43 |
|
whartung |
well for databases, we don't have breaking changes. Our apps update their database every time on boot. |
| 21:44 |
|
whartung |
which is 99.99% of the "breaking changes" |
| 21:44 |
|
whartung |
everything else is done as a script attached to the release notes, or part of the commit, since container tweaks are scriptable |
| 21:45 |
|
whartung |
last result a note with a lot of ***** to tell folks to pay attention |
| 21:51 |
|
whartung |
the auto updating database is the bees knees. that's a super great feature |
| 21:51 |
|
whartung |
and the devs work against their own db copy |
| 21:52 |
|
pdurbin |
yeah, it's the database scripts that are a killer |
| 21:54 |
|
whartung |
there's atool out there, Liquibase? I think? that does something similar to what we do |
| 21:54 |
|
whartung |
we maintain a file of delta changes |
| 21:54 |
|
whartung |
and on start, we run through the file, note which ones have not been played, and play them (and note they've been played). |
| 21:55 |
|
whartung |
every time the app deploys, that happens. |
| 21:55 |
|
pdurbin |
sajjadg mentioned http://flywaydb.org earlier but I didn't look yet |
| 21:55 |
|
whartung |
to deploy a new instance of the app, simply create an emptydb and start the app up |
| 21:55 |
|
whartung |
works a treat |
| 21:56 |
|
pdurbin |
it does work like a treat to drop your database and have the deployment set it up again |
| 21:56 |
|
pdurbin |
except all the data you were testing with is gone |
| 21:56 |
|
pdurbin |
once we have more APIs I can script some data creation |
| 21:56 |
|
whartung |
but that's not what I said we did |
| 21:57 |
|
whartung |
that's a side effect of the tool |
| 21:57 |
|
whartung |
is that it can start with an empty db |
| 21:57 |
|
whartung |
but obviously we almost never do that in development |
| 21:57 |
|
sajjadg |
flyway can handle the data creation too |
| 21:58 |
|
sajjadg |
go for it pdurbin ;) |
| 21:58 |
|
whartung |
data creation is just INSERT statements for us |
| 21:59 |
|
whartung |
but the incremental DB updater is the way to do. I have no faith in those "make the DB look like this" tools. |
| 21:59 |
|
pdurbin |
whartung: I don't want to INSERT data directy via SQL. I want to POST JSON via an API so all the backend code (i.e. bean validation) is honored. We have this for some types but not others |
| 21:59 |
|
pdurbin |
sajjadg: maybe :) |
| 22:00 |
|
whartung |
Ok, whatever. that means the application has to be up and running to post data -- and that's kind of zany, frankly. |
| 22:00 |
|
whartung |
for static data |
| 22:01 |
|
whartung |
if you're talking about loading test data, or something, that's a different. |
| 22:02 |
|
pdurbin |
well, the rules for the data keep changing. a lot of the pain stems from the fact that this is greenfield development, I think. we know generally what we're building but not exactly. the foundation changes |
| 22:03 |
|
pdurbin |
whartung: this "autoupdating database" of yours is a product one can buy? |
| 22:03 |
|
whartung |
no, it's internal |
| 22:04 |
|
whartung |
this is a similar idea afaict, not having used it |
| 22:04 |
|
whartung |
http://www.liquibase.org/ |
| 22:04 |
|
* pdurbin |
looks |
| 22:04 |
|
whartung |
we decided not to bother changig over to it, didn't seem to do anything more exciting that was we already did here |
| 22:05 |
|
pdurbin |
whartung: the way yours works is by running through the file of deltas you mentioned? |
| 22:05 |
|
whartung |
yes |
| 22:05 |
|
pdurbin |
ok. I think I get it |
| 22:05 |
|
whartung |
we may have 1000 deltas in our file, but only that last few will run at any given time, since it's a catchup |
| 22:05 |
|
whartung |
(unless the db is empty) |
| 22:06 |
|
pdurbin |
what if you run through the deltas file a few times for kicks? does everything break? or is it idempotent? |
| 22:06 |
|
whartung |
no, they only run once -- a history is kept in the database |
| 22:06 |
|
whartung |
so it knows where its at |
| 22:06 |
|
pdurbin |
ok |
| 22:06 |
|
pdurbin |
yeah we don't have that |
| 22:07 |
|
whartung |
yea, that's the key |
| 22:07 |
|
pdurbin |
instead we dig through email for a delta script |
| 22:07 |
|
whartung |
yea, that's insane |
| 22:07 |
|
pdurbin |
or we drop our databases and start over :( |
| 22:07 |
|
pdurbin |
yeah :( |
| 22:07 |
|
pdurbin |
whartung: but you had to build something to solve this |
| 22:07 |
|
whartung |
yea, but we built it 7 years ago lol |
| 22:08 |
|
pdurbin |
:) |
| 22:08 |
|
whartung |
today I'm sure we'd look at this liquibase thing |
| 22:08 |
|
pdurbin |
makes sense |
| 22:08 |
|
whartung |
we finally, just 2 weeks ago, added store proc support |
| 22:09 |
|
whartung |
we don't use many stored procs |
| 22:09 |
|
pdurbin |
fancy |
| 22:09 |
|
whartung |
but we resurrected a project that did |
| 22:09 |
|
sfisque |
pdurbin what whartung describes is not an uncommon solution. schema versioning with an app that self patches it's db. |
| 22:09 |
|
pdurbin |
oh, I'm sure it's a common problem |
| 22:09 |
|
whartung |
and you can't keep posting 1000 line SP sourcs in to the delta for a typo change everytime -- gets unwieldly |
| 22:09 |
|
sfisque |
though this liquidbase things looks interesting |
| 22:10 |
|
whartung |
yea the scheam differs, that's crazy talk. I never liked those. the diff model is much, much better |
| 22:10 |
|
whartung |
we also have Java steps where we can put java classes in to the update |
| 22:10 |
|
whartung |
(we mostly use those to update ldap schemas) |
| 22:10 |
|
whartung |
and, no, we don;t just blindly run these on production systems with a billion rows. They're handled individually. |
| 22:11 |
|
whartung |
most of the changes are just fine |
| 22:11 |
|
whartung |
but sometimes we have significant refactorings we need to do, and it's just not efficient with zillions of rows. |
| 22:12 |
|
whartung |
afk |
| 22:13 |
|
pdurbin |
are http://erwin.com or http://www.red-gate.com/products/sql-development/sql-source-control/ in this problem space at all? I hadn't heard of them but they were in an email with the subject "Database Object Source Control" where someone asks "What are y’all out there using to keep versions of your database structures over time?" |
| 22:14 |
|
pdurbin |
maybe that's a different problem. I don't know |
| 22:15 |
|
sfisque |
erwin seems to be the common solution. i've seen it used in several shops |
| 22:16 |
|
pdurbin |
sfisque: for my problem or for some sort of "versions of your database structures over time" problem I don't immediately have? |
| 22:17 |
|
sfisque |
not sure what your specific problem is. i've seen it used by "the dba's" to manage the schema metamorphosis over time |
| 22:17 |
|
semiosis |
pdurbin: our db schema is generated from our entities by hibernate. we use the maven hbm2ddl goal to write the ddl out to a file at any point in time. |
| 22:18 |
|
sfisque |
how does that translate against a running production system? |
| 22:18 |
|
pdurbin |
semiosis: someday we'll get you on an abcd list if you beg us like agoddard did ;) |
| 22:18 |
|
semiosis |
pdurbin: and use the diff between two DDLs to write a db update script which devs need to run. this script goes in the ticket that made the schema/entity change. |
| 22:19 |
|
semiosis |
you should be begging me |
| 22:19 |
|
pdurbin |
true |
| 22:19 |
|
semiosis |
lol |
| 22:21 |
|
semiosis |
sfisque: the db update script is written on a dev's local machine, then tested on the test environtment, then tested *again* on the staging environment, then finally run on prod. most of the time we can update the DB then update the code. for truly breaking changes we schedule a maint window, but that's rare |
| 22:21 |
|
semiosis |
for example, if we're adding a column, that can be done on the db and the current code will just ignore it, then we deploy the new code to use the new column |
| 22:23 |
|
pdurbin |
semiosis: so that diff that devs run sounds similar to the deltas file whartung runs |
| 22:24 |
|
pdurbin |
well, the db update script that's generated (magically?) from the diff |
| 22:25 |
|
semiosis |
it's a manual process... take two ddl files and diff them. usually it's enough to just execute the new statements. sometimes not. |
| 22:25 |
|
pdurbin |
hmm. well, it sounds like I should play with it |
| 22:26 |
|
pdurbin |
javaeebot: lucky maven hbm2ddl |
| 22:26 |
|
javaeebot |
pdurbin: http://mojo.codehaus.org/hibernate3-maven-plugin/hbm2ddl-mojo.html |
| 22:26 |
|
semiosis |
the other day we added a table which is referenced by two existing tables... so we took the new table's create statement, and modified the two existing tables' create statements into alter smtms |
| 22:26 |
|
semiosis |
stmts |
| 22:26 |
|
pdurbin |
semiosis: wait, is this a hibernate-only thing? we use JPA |
| 22:26 |
|
semiosis |
jpa is an interface... you need some implementation behind it |
| 22:27 |
|
semiosis |
we use hibernate behind jpa |
| 22:27 |
|
pdurbin |
sure |
| 22:27 |
|
pdurbin |
but does hbm2ddl require hibernate? |
| 22:28 |
|
semiosis |
idk |
| 22:29 |
|
pdurbin |
:/ |
| 22:29 |
|
semiosis |
i'd imagine any jpa impl can write out the ddl |
| 22:29 |
|
semiosis |
i mean, it executes the ddl |
| 22:29 |
|
pdurbin |
well, an interesting tool nonetheless |
| 22:29 |
|
semiosis |
https://code.google.com/p/eclipselink-ddlgeneration-maven-plugin/ |
| 22:29 |
|
semiosis |
looks like the equiv. for eclipselink |
| 22:30 |
|
pdurbin |
yeah, that's what we use. eclipselink |
| 22:30 |
|
semiosis |
then give that a try |
| 22:30 |
|
semiosis |
http://stackoverflow.com/questions/5992031/generate-ddl-for-jpa-2-0-with-eclipselink |
| 22:31 |
|
pdurbin |
MAYbe I will |
| 22:31 |
|
pdurbin |
and maybe I'll sound all smart when I reply on the abcd list ;) |
| 22:32 |
|
pdurbin |
for a change |
| 22:32 |
|
semiosis |
hah |
| 22:33 |
|
semiosis |
well, time to go. good luck with that |
| 22:34 |
|
pdurbin |
o/ |
| 22:37 |
|
|
AndroidLoverInSF joined ##javaee |
| 23:05 |
|
whartung |
pdurbin: so, just to note, as a rule I make all of my changes using the delta tool. I write the script to do it by hand (most changes aren't that huge), and run it from there. Notably, I don't run sql against the DB by hand, I use the tool. That way I always know it works, and I don't have to un do changes and such |
