Auto Generate Update SQL? #96
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: joomla/Component-Builder#96
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi Guys,
This is looking very promising. I've been using CC for a year on and off.
I'm struggling to see two things and this maybe my limited view after using CC.
Many thanks
Tony
Yes JCB does all those things and so much more, in fact that is some of the most basic things it does.
You can try it out, extend it your self, or purchase some of our demo components here.
Get Access to Video Tutorials
GET ACCESS NOW!
I've actually found most of this out now on my flight back from JAB. Just takes a bit of getting used to.
Also, can you point me in the right direction... from what I can gather so far if I make changes and then upgrade a site I need to write custom MySQL for the upgrade routine. Is that right?
Yes this is how it works at this time in JCB so when it compiles your component it will add the sql (you wrote) dynamically. We are working on the option to also automate the writing of the SQL, to check for changes like more or less fields in a view, but I am just not getting to everything :) how is your PHP?
I think JCB is the next revolution to Joomla component development, but we need guys who are willing to get involved on a code level. That is why I opened it up to the public... it is to big for one guy.
But yes you can install JCB on your own Joomla website, and then start development (preferably off-line) it also can setup the update server per component, push via FTP and more coming soon 👍
Looks good to me! I'll see if I can get sometime to code it in, given this should save me tons of time anyhow :).
Yes it sure will! I have written over 1 million lines of code with it in just 6 months.
Impressive, I've been using ComponentCreator and it's good. But it costs, and if I take a few months developing a component I'm on budget with it's an expense I could do without. Plus, it doesn't have half the functionality this offers! But does have auto update SQL Generation 🤣
On 5 Jun 2017, 18:39 +0100, <>yn notifications@github.com, wrote:
We can solve that one soon, even sooner if you helped. I will give some pointers to how I thought to do this, have to run now... later!
I'll interject "my two cents worth". I tested several component "building" components and services before I settled on JCB. I wanted an "all in one" location to not only build, but easily maintain versions.
When I started building my component, I will honestly say that I had very limited experience with PHP. But other the months I have become more proficient in PHP. PHP, as is stated, is a MUST for not only JCB, but any component building.
Component builder, although confusing at times due to it's complexity, is very handy. In the past several months I went from having some written out notes, to a component with, according to the last build, over 102,000 lines of code. It's not 100% complete, but is now in beta.
I can't say that this would have been possible without JCB.
And, as far as code "cleanliness"? I brought in a professional Joomla developer to assist with some Javascript functionality (i.e. javascript filtering of content, maps, etc). As he stated "I have worked on quite a few components for people, but it was an absolute pleasure working on yours with such clean, well structured code."
It's based on the Joomla! MVC and shouldn't write any of its own code just base of how it should be done correctly so I'd hope it's clean :).
I'm ok with PHP and actually help out with core Joomla! Code too.
I've found a couple of bugs I'll see if I can get around to fixing soon.
Great bit of work so far though for sure!
Okay about the dynamic implementation to build the sql for new tables, fields and/or the removal of them.
JCB does not keep track per se of these concepts. Meaning it has not way to know that things changed. Yet that does not mean it can't, so my idea is to base the changes on the database of the installed version of any given component. But if the component is not installed on the site where JCB compiles it will not be able to detect the changes, or so my own logic follows.
The second way is to create a new class that checks the history of each view and during compilation if it detects there has been a change, parses the fields to see what has changed, taking the last values out of the history component and match them against the current values and so formulate the SQL updates. Further it also should do the same for components, in effect adding the needed tables as need or removing them.
Yet all these automation could potentially remove tables and fields that is unexpected. One may instead rather want to just rename. So this means we will need to somehow address these variations, any ideas?
So there are these two options, one use the current DB of the installed component to detect changes, two use the history component.
I am willing to add this feature since it has been requested before, and seems like a must have. So share your thought and I will get started.
So Re Joomla! 4 it's mainly moved to namespacing and preventing advising the overloading functions and methods is to be removed in J4.1. 3.9 extensions should work on 4.0. But likely not in 4.1 with their new magically compatibility layer since they do not want big breaks like 1.5-1.6 was.
Re the update SQL. Second seems better to me, and no need to add a remove function into the build cycle of the SQL. I'd like to see the tables left behind or at the most add a config option to all removing tables if you delete one and so on. Since if it's a user error they could just add it back in and the code can pickup existing data.
You could also add this as a config option that is on by default.
Okay so we need to add a few more switches to component view, and lets go with the history component (second option).
Now here is a question. JCB already has an area that tracks the update SQL in the Joomla Component view. These updates are linked with version releases of course. This because Joomla only updates the DB when it sees a new version, like here. So the question is how to automate the version incrementation? and I would think that if the developer wanted to do some smart DB tricks beyond the default, he can add the SQL before and JCB should realize it needs not build it dynamically.
What will be a good convention, for example:
Why not make it auto-incremental on compile? since 99% of the time when adding/removing fields it will be done and ready. I appreciate you are trying to follow sym version, but I don't think that's important here. Just allow an override to the version number should users want to make it a 4.1.x release then they could? The compiler just adds +1 to the 4.0.1
Well, this is actually not so simple. I have seen in my own experience that the compiling of the components gets done many times over and over. You would hardly want to increment automatically each time.
So we will go with the above mentioned idea of automatic incrementation, yet leaving the option to override it manually in the Joomla Component view.
Well I would actually want it to add a version number on each compile so it's understandable. And if you compile you are going to install this a different version it breaks sym ver if you don't, but your approach would work fine for me too.
I would probably change Compile to Build Component, so it's more User Friendly and not developer focused.
And also allow a way for building it into folder and not into a zip. So for development reasons you can SymLink the folder into Joomla!
Just more ideas ;-).
Well it already does build to a folder 👍 we call that the git folder option. It does it with each compile.
Ahh that's was GIT Folder is ;-)
This is really a component for developers, no need to target none developers. If they don't understand, this is okay. I mean the lack of understanding protects the program from being used in a way that will destroy the Joomla app development market. So complexity in this regard is good, and therefore using dev terms is excellent way to attract the right audience.
But hey, who knows where this little project will go... if it becomes a full fledge community project, this direction may change.
I would like to transform the git folder build into a testable concept, like the weblink project in Joomla repos. Could you help me with that?
I am not that experienced with those things yet, but I know it is the right direction.
To automate that kind of implementation is what I would like JCB to do for each component it builds/compiles.
How do you mean a testable concept? So the web links is a way of Joomla! Removing the dependency to the core. So it's uninstallable, but it's been a nightmare for Joomla! To manage so there is talk about migrating them all again...
hmm okay well there you go... it just shows you how little I know. But here is what I want to achieve, testable as to easily link to Travis CI or Jenkins so that all commits of a component, yet without Joomla in the same repo can be tested.
SO a way for JCB to build unit test for each component... well that may be to much, but hey it will be amazing if we can go that direction. Maybe not right now... but a goal for the future.
SO my focus on the Weblinks is not they way it gets linked to Joomla but the way it gets tested.
Sorry I know this is little of topic...
Right so you want a travis setup! They are using travis, drone, appveyor at the moment.
But most require an additional or multiple servers to do the audits and tests. At the moment I don't think it's needed at this level, only when your in more demand. Joomla! Needs them to keep up standards since it's powering millions of websites.
I know... it is just that it sets up all the hooks and documents needed to link it, for those who will start developing components with JCB that will target thousands...
Like the git folder option, we can add a switch that allows you to add the needed files and info to your project.
I know it may be to much, but if your project cross the 200 000 lines and it is used by thousands these kind of things will make your life so much easier.
I suppose it could be, buts it's only relevant to users who push to GIT and allow users to contribute.
Users developing can install and setup Codesniffer from the Joomla! Repo to follow Joomla! Standards too. phpStorm is amazing with this too!
Many thanks
Tony
For Travis see:
https://travis-ci.com/plans
And ask if you can get an open source one :)
@tonypartridge adding the automation for the SQL updates has become seriously complex, since views and fields are used in multiple components.
I had to overcome the reality that history gets dumped after a set amount of changes, and that each component is targeting different times of the history of any given view or field. But at last that is done!
I am nearly halfway with the code, at this time we are targeting four concepts:
Do you think there is more changes we should target?
Ouch!
That sounds all about right. I can't see anything else you would need to automate at this time
On 13 Jun 2017, 14:39 +0100, <>yn notifications@github.com, wrote:
@tonypartridge have a look at this video