G'day Hans, That sounds wickedly interesting, but way beyond the scope of my project, I think. I reserve the right for a long chew, or long bout of paralysis by analysis.
What I'm building is the kind of thing that would spit out DDL (i.e. the create statements for tables, indexes, views, foreign/primary/etc. constraints), the kind of stuff to create a database. Not the kind of stuff for interacting with a database via SQL (select, insert, update, delete). Using TiddlyWiki to access a database has been simmering in the far recesses of my mind, but that is a complicated affair, a whole bunch of technical skills I don't have at all. However, if we are talking get TiddlyWiki to generate SQL statements that can be cut and pasted into other software that accesses a database, that could be a fun project, although likely one for a year or two down the road. If TiddlyWiki can spit out DDL, it can equally spit out SQL. So many possible projects, so few hours in a day. Other projects I've been tossing around in my head: a TiddlyWiki Report builder (kind of like Crystal Reports?), and a TiddlyWiki Forms Designer. On Saturday, February 27, 2021 at 4:55:37 PM UTC-4 [email protected] wrote: > cj.v: > > I've been watching your ideas with considerable interest since I have > access to a LOT of realEstate/property data and I am surrounded by a large > group of SQL experts. (For my part, it's been at least 20 years since I > used SQL and, now, I would/should be blocked from doing so again by the > techs I work with). > > I cannot help but wonder is there is enough synergy that we might be able > to propose/build a bit of a prototype of how TW and SQL might interact > (even if only at the Design stage). I'd be content to explore this further > using email either at [email protected] (Professional use - heavily spam > filtered, so I might need to punch a hole for you) or [email protected] > (Personal use). > > Cheers, > Hans > > On Saturday, February 27, 2021 at 10:26:56 AM UTC-5 [email protected] > wrote: > >> For sure, Stan. I've got to iron out some kinks, and figure out how a >> user could upgrade from one version of Tifoist to the next (i.e. never need >> to re-enter or fix anything in an upgrade.) >> >> Once I can get the basic functionality working, I will throw myself into >> figuring out how to build a Tifoist plugin. >> >> I'm thinking, very much on the fly: >> >> - Testing of basic functionality first. Iron kinks. >> - Well, once I finish "basic functionality", (the scope is a >> moving target right now.) >> - Setup Tifoist as a plugin, then test that and iron out kinks. >> - Then work on Tifoist upgrading. Test and iron out kinks. >> - At some point, test TiddlyWiki upgrade of a TiddlyWiki with Tifoist >> plugin. >> - At some point, and in logical chunks, add more functionality, while >> making sure none of the above get broken. >> >> >> I've spent *the last few days hyperfocused on GUI design* (i.e. making >> the TiddlyWiki look like an an application for domain "modeling" and >> database engineering, maybe even software engineering). >> >> Also a little sidetracked by naming paralysis by analysis. >> >> Anyhoo, latest incarnation for your viewing pleasure and scrutinizing: >> Tifoist-TW5 >> Prototype 2 >> <https://tifoist.neocities.org/CJ_TIFOIST_BIS_PROTOTYPE_V2.html> (continuing >> to model a domain I know well: the business domain of New Brunswick's >> Buildings Group, related information about 2/3rds of the way down this >> page >> <https://www2.gnb.ca/content/gnb/en/contacts/dept_renderer.149.1699.html#mandates> >> .) >> >> On Saturday, February 27, 2021 at 8:50:23 AM UTC-4 [email protected] >> wrote: >> >>> This looks really nice, Charlie. Let me know when you are ready for >>> some beta testing. I have a couple of nice book projects where I could use >>> Tifoist. >>> Stan >>> >>> On Tuesday, February 23, 2021 at 10:05:14 PM UTC-5 [email protected] >>> wrote: >>> >>>> "ORM-ish à la TiddlyWiki" is now "*The Tifoist Project*" >>>> >>>> - *T*ifoist *I*s a *F*act-*O*riented *I*nformation-*S* >>>> emanticization *T*ool >>>> >>>> >>>> The previous work I now call "prototype 1." >>>> >>>> I am now labouring on "prototype 2", involving some GUI design and >>>> overhauling/refactoring what I did in prototype 1. Much of what I did in >>>> prototype 1 is now broken in prototype 2. >>>> >>>> Much work to do before prototype 2 can be released into the wild for >>>> some scrutiny. For now, I share a few screenshots (attached). >>>> >>>> Cheers ! >>>> >>>> On Tuesday, December 1, 2020 at 4:49:31 PM UTC-4 Charlie Veniot wrote: >>>> >>>>> Project TiddlyWiki: ORM-ish à la TiddlyWiki >>>>> <https://intertwingularityslicendice.neocities.org/CJ_ORM.html> >>>>> >>>>> *BTW: My announcement for this project has turned into an awesome >>>>> thread of discussion. Please check out Using TiddlyWiki for fact-based >>>>> information modelling and database engineering ??? >>>>> <https://groups.google.com/g/tiddlywiki/c/57_eiPadjCo> for some >>>>> ridiculously excellent buffet of food for thought about, um, thought >>>>> (cognitive processing). Things like (I can't do it all justice):* >>>>> >>>>> - *managing complexity* >>>>> - *information/knowledge design/navigation* >>>>> - *PhD-related stuff about context and keeping stuff >>>>> understandable* >>>>> - *in short: A LOT OF WOW GOODNESS !!!* >>>>> >>>>> *Latest Updates* >>>>> *(The following pretty much sums up changes/additions since November >>>>> 23rd.)* >>>>> >>>>> *Text Rotation Testing* >>>>> >>>>> - I took a little side trip trying to figure out a generic >>>>> mechanism from creating tables like in the "Entity Relationship >>>>> Matrix" >>>>> tiddler. Although I gave up after a few hours (much too big and messy >>>>> of a >>>>> job), I left the following two tiddlers in the TiddlyWiki in case I >>>>> ever >>>>> want to try again: "Research Macros" and "Text Rotation Tester" >>>>> >>>>> *Coded Form of Facts* >>>>> >>>>> - I last had coded form of facts setup as one field for each fact, >>>>> containing the entire coding line (for example: coded field = >>>>> "BUILDING >>>>> 1:1 BLDG_NAME"). >>>>> - That was making all of my scripting more complicated (having to >>>>> split that coded field into the three parts: BUILDING, 1:1, and >>>>> BLDG_NAME >>>>> for whatever kind of processing.) MORE IMPORTANTLY: that was making >>>>> it >>>>> much more difficult for me to setup "data entry" of a fact's coded >>>>> form via >>>>> select widgets. >>>>> - Now, a fact's coded form is split into three fields: c1, c2, and >>>>> c3. (for example: c1 field = "BUILDING", c2 field = "1:1", and c3 >>>>> field = >>>>> "BLDG_NAME".) >>>>> - This change from one field to three required some rejigging of >>>>> various tiddlers, including (among others): "Entity Relationship >>>>> Matrix", >>>>> "oEs" (a transclusion template to generate conceptual representations >>>>> of >>>>> entities; see "BLDG_SPACE_UNIT" tiddler for an example) >>>>> >>>>> *Early start (experimentation) of widgets for data entry* >>>>> >>>>> - Using "select widgets" to help with creating coded form of >>>>> facts. I'm very new to the use of widgets for this purpose, so this >>>>> will >>>>> take me a while to get right. For a starting example, see the "A >>>>> Building >>>>> has exactly one Name / A Name is unique to a Building" fact >>>>> >>>>> *Entity Relationship Matrix tiddler* >>>>> >>>>> - For the slanted column titles, I removed the little links for >>>>> the related tiddlers, because the slanting of titles often causes the >>>>> tiddler links to not be clickable (they wind up at the bottom of >>>>> "z-order", >>>>> and it just isn't a fun thing to try and fix at the moment.) >>>>> - Pure CSS for tooltips on the check marks is wonky sometimes >>>>> because of tooltip positioning (which can only be auto-adjusted nicely >>>>> to >>>>> show the tooltip, in a guaranteed viewable spot, with javascript.) >>>>> That is >>>>> not a fun thing to try and fix at the moment. >>>>> - Scrolling the table columns towards the left: modified so that >>>>> when columns get slid over to the left, the cells don't show on top of >>>>> the >>>>> row headers on the far left (that remain in fixed position.) >>>>> - I haven't figured out how to do the same for column headers, but >>>>> I'm on the fence: not sure I want to hide column headers when >>>>> columns are >>>>> scrolled to the left. >>>>> >>>>> *Primary Keys for entities* >>>>> >>>>> - I was setting up all primary keys as "value_type" tiddlers, but >>>>> I've modified so that primary keys are now specified as a simple field >>>>> on >>>>> each related entity tiddler. >>>>> - Seeing as I'm a big believer in using Sequence Numbers (as per >>>>> Oracle Database products; whatever is equivalent in other database >>>>> products), it doesn't make much sense for each primary key having a >>>>> dedicated tiddler. >>>>> - Instead, every entity has a sequence number name specified in >>>>> a field, and each sequence number follows the exact same standard >>>>> (data >>>>> type, max length .... all of which are currently hard-coded in >>>>> scripts; I >>>>> plan to move those "standard sequence number details" in a data >>>>> tiddler). >>>>> - BTW: Related oEs template tiddler (for conceptualisation of >>>>> entities) modified accordingly. >>>>> >>>>> *Conceptualisation of Entities* >>>>> >>>>> - For each attribute, the table now shows the related fact in a >>>>> new column on the far right side. (Just nice extra information about >>>>> each >>>>> attribute). >>>>> - TODO: setup some mechanism to specify an order for the >>>>> attributes (likely up/down buttons with saving position in related >>>>> fact >>>>> tiddlers; still thinking about it.) >>>>> >>>>> *Task Tracking* >>>>> >>>>> - Renamed "Facts - Coded Form Pending" to "Facts - Incomplete >>>>> Coded Form". >>>>> - Got rid of "Entities/Attributes Pending Creation" tracking >>>>> because "Facts - Incomplete Coded Form" handles that. >>>>> - Added "Entities - Incomplete Primary Key" tracking. >>>>> >>>>> *Entity "... to Many" relationships with value types or with other >>>>> entities* >>>>> *(getting into some heavy-ish relational database design stuff here >>>>> ...)* >>>>> >>>>> - In simple "... to 1" relationships, this would translate into >>>>> one table for the one entity (for an entity relationship to a value >>>>> type), >>>>> or a table each for the two entities (for an entity relationship to an >>>>> entity). Easy peasy. >>>>> - However, for a case of "... to many", that introduces an >>>>> additional table for both scenarios (1. relationship to many value >>>>> type >>>>> instances 2. relationship to many entity instances.) >>>>> - That's something I need to ponder on: i.e. how to handle >>>>> writing facts, coding those facts, and conceptualisation entities >>>>> (i.e. the >>>>> related scripts) >>>>> >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/cd9393b9-3bbe-4376-860b-6e1cdfd55cben%40googlegroups.com.
