#bookbrainz-devel

I've added a check for publisher_gid being None, and if it is, set the uri to null

LordSputnik, does that prevent it from being output?

No, we can't do that

it just outputs as null

Blergh. Okay.

It's probably actually nicer - then at least the field is always there

bookbrainz-ws/master 37d930a Ben Ockmore: Included identifiers url in entity responses, added PublicationEditionsResource (yuk).

We can sort it out when we restructure, I suppose.

bookbrainz-ws/master 402485f Ben Ockmore: Added endpoints to get revisions for users and entities.

Leftmost: what should we do about revision diffs for now?

How do you mean?

Well, what are we going to display in revision history besides revision number and note, when we have no way of getting the difference between two revisions at the moment?

I can take a crack at writing a diff tool for -site.

Leftmost: https://www.npmjs.com/package/data-diff

Neat.

If you run that from r1->r2 and from r2->r1, it'll give you two lists you can use to work out added/changed/removed

We could write a fairly simple tool also that took in a model and ran through each of its fields to see if it had changed.

yeah true - whichever is simplest, since we might want to put this in the WS next month :P

I'm still not convinced that it belongs in the WS, since it's a display issue and can be easily replicated.

Leftmost: the thing is, that might get complex with aliases and identifiers

(method 2 vs. data diff)

You could data-diff the two models at r1 and r2, which would probably work well, and handle all the recursion too

I think it should be fairly simple, but I'll evaluate it to see which method will work best.

OK :)

Leo_Verto: Add the config file to .gitignore and include a configfilename.sample instead.

http://waveplot.net:9099/editor/4/revisions :)

Nice.

LordSputnik, which would be more helpful for me to address first: search-mediated select or diff?

Leftmost: well, I think search is probably higher priority

Okay.

I need to create issues for myself.

Hmm. Search brings up another "feed the WS URL to the UI or create an intermediary endpoint" issue.

I had an idea the other day that's definitely a long-term thing, but probably worth thinking about: instead of separating the WS and the frontend (and thus requiring redefining models and all that), have the WS be generated automagically from the models in the -site code. This isn't something I'm going to start hacking on this week, but could you do some thinking about benefits and pitfalls?

how, though, when the site code is node and the WS is python?

Unless you use JSON as a common thing between the two

I was thinking that the two would be folded together. Instead of the WS being a lower layer than the site code, it would be just another representation of the same data, generated automatically from the model definitions the rest of the site uses.

But the schema is Python, so how can the WS not be?

It would depend on the site code accessing the database directly. As I said, it's long-term.

I don't think that's a good idea

Everything should go through the WS

And I think they should be separate

We should be able to do anything in the site that we can't do in the WS

Otherwise our code ends up like mb-server :P

The biggest benefits I see are in data handling. We'd only need to define the data representation in one place and it would reduce the overall complexity of our code.

Defining the data in two places hasn't been a big issue for us so far

Also, the complexity would increase because we'd have to incorporate DB access into the models, which is a pain in node

We could create a language agnostic set of data structures defining the data models, then just pull them into node and python

That would be bb-data, and we could then pull them into -site and -ws

LordSputnik, I just think it's unnecessarily complex to pull code from the database, translate it into a usable representation and then serialize it, then deserialize it, process it again, and then serialize it for display.

OK, but the transfer to site has to be in JSON, and it has to be from a separate system

If there's another system that can satisfy that, then I'd probably be fine with it

A separate system how?

Well, separate from the site code

Ahh, right.

Otherwise other people can't use it

And using a WS to get site data forces the WS to be good (or at least good enough for us)

We could modularize it still, make it a node module for accessing the database and present the results as JS objects.

There's no such obligation for MB, which is why their WS isn't very good

Yeah. That's why I was thinking it should be auto-generated from the models.

that's what we had at the beginning, but the relational database packages for node are all much worse than SQLAlchemy

MB doesn't really have true models, but if we ensure that the models used for the site are the same representation as goes out to the WS, then we have a guarantee that there's no difference in capabilities.

Yeah. node's ecosystem is obviously pretty young still, so I think we'd be best served looking at this as very long-term.

OK

Wait and see if a node module pops up with more mature DB handling and suchlike.

Definitely not a June feature. :)

What do you think of the proposal of defining our models in JSON and importing them into both the WS and the site?

It's an interesting thought, definitely. It'd be easy to split out the models too, since they're almost JSON as it is.

I'm not sure how well nested objects would play with that

How we'd translate that into something usable for python is less clear to me, but that doesn't make it a bad idea, since python is generally not very clear to me.

Well, I can convert the JSON to a dict, then match the dict properties to the schema model properties to fill out a data structure automatically

You mean like the ref/object fields? (Object needs to go away. It's just a placeholder for things which aren't proper refs right now, which is sort of moot anyhow since ref is the only field type that _does_ anything right now.)

yes, that

Well, right now those definitions are all textual anyhow.

I think we'll have to handle the ws/data/schema separation properly before we can work out how to abstract out the model definitions from our Python code

Yeah.

There's a lot of architectural work to be done, for sure, but we'll get there. :)

It doesn't make me incredibly happy, but I think I'm going to make a very thin search endpoint for the search selects.

Can't you use the existing search form handler?

Oh, maybe. Derp.

Didn't even think of that.

I don't know what that gives out though, it may do a redirect - you can probably put the code in some function and share it though

Did you decide on a date for next release?

Freso, tentatively Friday.

LordSputnik, could always just parameterize it.

Mhmm :)

Ok, I've got multiple aliases working on create/edit, and default/primary selection too - there's an issue on the WS, but hopefully that won't be too bad to fix :P

Leftmost: currently when you don't provide any aliases for an entity, it shows up on the front page with the name "(unnamed)", and without a heading on the entity view page

Is this what we want?

I'm slightly concerned that "(unnamed)" may seem like a legitimate title

can you think of a better way of representing it?

If you don't require any, you can at least require confirmation that they indeed want to do that I guess

(if you don't have it already, that is :) )

My biggest concern is how to make such entities searchable, discoverable, discernable, displayable. I'm also not sure about the use case you presented, LordSputnik. Can you come up with an illustrative real-world example?

Well, a book has illustrations, but no illustrator is listed. So you make a blank Creator, and set the "X illustrated Y" relationship

(no pun intended)

Which indicates that *someone* illustrated the book, but they aren't currently known. If someone later finds out who it is, they can set the name, or merge it into another entity

It seems more natural to do that than create an artificial [unknown] entity

I think I prefer the SPA-type entities to that solution. It gathers such entities and relationships into one place nicely, it prevents us from having entities which will never conceivably have aliases (I'd rather "[unknown] authored Beowulf" forever than "(unnamed entity) authored Beowulf"), and it requires less special-casing throughout the code.

I'd say either use SPAs or allow true empty rels but something in between does feel a bit weird to me, yeah. But dunno :)

SPAs also allow for shades of meaning, I think. An unnamed entity could have any number of reasons for being unnamed, but you can specify those reasons with SPAs.

I don't want to change all that for May

I don't mind doing it in June though

LordSputnik, I wasn't thinking we should do it for May.

bookbrainz-site/master 23aa532 Ben Ockmore: Added revision history display - no revision detail yet.

I have no idea how to render react elements to a string for use by client-side JS. :-P

o_O

react is all client-side, you only need to render them to a string if you want to render them server-side

(and is probably a combination of React.renderToStaticMarkup and React.renderToString calls)

+that

bookbrainz-site/master d19554e Ben Ockmore: Added bootstrap style fixes to select2 file - see https://fk.github.io/select2-bootstrap-css/

kuno: we're pre-rendering most of our react server-side

(or aim to be)

kuno, right, but I'm trying to template select2 results, which involves getting a string of HTML to feed back.