[rules-users] Guvnor JCR repository
Mark Proctor
mproctor at codehaus.org
Sun Feb 9 17:45:15 EST 2014
I’m not sure what you think was lost. All the 5x use cases should be catered for.
> Once you are in prod and you just modify a rule, how do you do ?
Not sure what you meant by the above?
I don’t see that anything was lost, compared to 5.x Instead we have better foundations, built on industry standards. Over time we can figure out how to best expose those layers in the UI, or how to make things smoother with task oriented UIs (wizards) to drive things.
But in the mean time your devs and admins have clean ways of doing things, that wasn’t available in 5.x.
We are thinking of adding “git flow” type functionality, where development is done in “feature branches”.
http://danielkummer.github.io/git-flow-cheatsheet/
The main difficulty here is finding a sane way to handle the flow, as we can’t expose merge conflicts to end users in the UI. Especially as XML and blobs have no effective way to do merging. As commits can be squashed, when the feature branch is merged, it can help reduce the history size, and keep it more relevant.
i’d be very interested to hear from people how they think this can be done. What sort of “flows” can we build into the UI, that is suitable for BAs,that leverages the power of git, and avoids getting situations where code is lost due to merge conflicts.
In generally any feedback on how to improve the usability via higher level screens/wizards/configurations/workflows/task lists etc, is really welcome.
We also now have a very clean and extensible UI, so it’s easier for community people to work on things with us. Such as adding new wizards etc.
Mark
On 9 Feb 2014, at 21:53, Nicolas Héron <nicolas.heron.java at gmail.com> wrote:
> Yes Mark,
> But I do not see business analyst using git !
> the drools workbench of drools 6 is the dev tool that did never exist in the eclipse plugin for drools, this is sure. "traditional" = traditional for dev people I guess ?
> The same with maven, it integrates super well in development teams.
> Once you are in prod and you just modify a rule, how do you do ?
> so we lost the tool for business analyst in 6.x..
> I am impatient to see a 6.1 with new features that shall give us back all that :)
> It would be nice to have a good drools boot camp to discuss all those things.
> Cheers
> Nicolas
>
>
> 2014-02-09 22:06 GMT+01:00 Mark Proctor <mproctor at codehaus.org>:
>
> On 9 Feb 2014, at 20:30, Nicolas Héron <nicolas.heron.java at gmail.com> wrote:
>
>> Hi,
>> What you do is the only way to handle the increase of the jcr repository.
>> Do you use a external db (oracle, postgres, etc..) or the build in db in Guvnor ? I noticed many times that the default embedded takes a huge disk place. I am often using postgres as a persistent db for jackrabbit and the size is reasonable.
>> Just a note about Mark's remark on jcr, versus Git. Git contains history also and the items that are stored from the Drools workbench
> One of the main advantages of Git though is you can use traditional tools to manage this, such as rewriting history to squash commits.
>> are quit big also (XML file with hundreds of line modified per version in decision tables, etc..)., Just to say that it can become bigger also :)
>> And furthermore with guvnor/jackrabbit accessing element by status/categories is super fast because it is optimized in jcr jackrabbit.
>> Optimization is like index in relational databases, it takes disk place.
>> Cheers
>> Nicolas Héron
>>
>>
>>
>>
>>
>>
>>
>> 2014-02-09 16:39 GMT+01:00 Mark Proctor [via Drools] <[hidden email]>:
>> There is no easy way to deal with this in 5.5, other than importing and exporting. The problem no longer exists in 6.x, as we now use GIT.
>>
>> Mark
>> On 9 Feb 2014, at 15:30, Demian Calcaprina <[hidden email]> wrote:
>>
>>> Hi Guys,
>>>
>>> I am using Guvnor 5.5. For moving packages between environments, I am doing an export, and then import in the new package. I have a lof of assets in each package. I am using the DB storage for the jcr repository.
>>>
>>> After some months, the DB has grown a LOT! (like 3.5GB).
>>>
>>> Is there a way regularly clean the JCR history, or maybe disable JCR history as we are not using it at all?
>>>
>>> These are the steps I did to remove the history and seems to work fine. Does is seem safe? Is there a better way?
>>> 1. Export the entire repository via guvor.
>>>
>>> 2. Delete all the packages.
>>>
>>> 3. Stop tomact
>>>
>>> 4. “truncate” the following guvnor tables:
>>>
>>> a. Pm_ws_default_binval
>>>
>>> b. Pm_ws_default_bundel
>>>
>>> c. Versioning_pm_binval
>>>
>>> d. Versioning_pm_bundle
>>>
>>> 5. Restated tomcat
>>>
>>> 6. Import what I exported on step #1
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Demian
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>> If you reply to this email, your message will be added to the discussion below:
>> http://drools.46999.n3.nabble.com/rules-users-Guvnor-JCR-repository-tp4028025p4028026.html
>> To start a new topic under Drools: User forum, email [hidden email]
>>
>> To unsubscribe from Drools, click here.
>> NAML
>>
>> Nicolas Héron
>>
>> View this message in context: Re: [rules-users] Guvnor JCR repository
>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140209/2a9050a7/attachment-0001.html
More information about the rules-users
mailing list